Search Home Members Contacts
About Us
Products
Downloads
Community
Support
Pages: 1 [2] 3 4 ... 6
  Print  
Author Topic: mako ( deferred framework )  (Read 70106 times)
ZaPPZion
Moderator
Community Member
*****
Posts: 571


« Reply #20 on: September 27, 2009, 10:46:56 AM »

ahh, thought so Smiley

Nevertheless, incredible stuff
Logged

Check out my website: www.bartkuipers.com
AriusEso
Customers
Community Member
*****
Posts: 940

Esoteric


« Reply #21 on: November 12, 2009, 06:58:08 PM »

Been a little while since I updated this thread. Mainly due to rewriting certain things to make them better.

Added custom splatting on landscapes. 4 diffuse( splat in alpha ) and 4 normal maps( specular map in alpha ).

[click for 1920x1200]


The framerate should improve once I add in the LOD etc.
Logged

-...-

Shadowsong
Customers
Community Member
*****
Posts: 328


« Reply #22 on: November 13, 2009, 02:12:55 AM »

Wow looks pretty cool!
This is exactely what I want to try soon, custom splatting. And intuitively I would have done the same, storing splatting info in the diffuse's alpha channel and specular info in the normal's alpha channel. So thanks for proving that it works Smiley
It would be nice to know if you went into some special troubles or had to make some fancy tricks to make this work.

Great work!
Logged
AriusEso
Customers
Community Member
*****
Posts: 940

Esoteric


« Reply #23 on: November 13, 2009, 03:43:44 AM »

Wow looks pretty cool!
This is exactely what I want to try soon, custom splatting. And intuitively I would have done the same, storing splatting info in the diffuse's alpha channel and specular info in the normal's alpha channel. So thanks for proving that it works Smiley
It would be nice to know if you went into some special troubles or had to make some fancy tricks to make this work.

Great work!

The only thing you must do is build the tangent and bitangent in the vertex shader as TV3D does not provide these for you. Other than that, ignore the fact it's deferred, you can normal map in the same way you would a mesh. Building the required information is simple.

Code:
//Whereby:
//
//t = tangent.
//b = bitangent.
//n = normal.


v2fout.t  = cross(a2vin.n, float3(1, 0, 0));
v2fout.b  = cross(v2fout.t, a2vin.n);
v2fout.t  = cross(a2vin.n, v2fout.b);
v2fout.n  = a2vin.n;
Logged

-...-

AriusEso
Customers
Community Member
*****
Posts: 940

Esoteric


« Reply #24 on: November 13, 2009, 04:27:23 AM »

[click for 1920x1200]
Logged

-...-

Shadowsong
Customers
Community Member
*****
Posts: 328


« Reply #25 on: November 13, 2009, 05:00:24 AM »

Wow looks like LOTS of grass Cheesy
Looks really nice!

What about the white outlines of the trees in the backgrounds? Looks like a problem with the deferred processing.
Also might I ask if you are still using TVTextures as RenderTargets or if you are using "true" MRT now?
Logged
AriusEso
Customers
Community Member
*****
Posts: 940

Esoteric


« Reply #26 on: November 13, 2009, 05:16:41 AM »

Wow looks like LOTS of grass Cheesy
Looks really nice!

What about the white outlines of the trees in the backgrounds? Looks like a problem with the deferred processing.
Also might I ask if you are still using TVTextures as RenderTargets or if you are using "true" MRT now?

What do you mean by true MRT?

TVTextures I assume you mean CTVRenderSurface? These are just wrapped DX render targets. I use MRT, TV3D supports these in its implementation. Dunno what you're referring too with "true" MRT though?

I have many buffer shaders for different object types but they all output in a similar fashion to an MRT structure, as such:

Code:
struct fmrt
{
float4 C0: COLOR0; //Colour.
float4 C1: COLOR1; //Position.
float4 C2: COLOR2; //Normals and Specmap.
float4 C3: COLOR3; //View and depth.
};

I have noticed that white outline also. I don't think it's a problem in the deferred process at the moment. I haven't investigated it yet. I think it's more an issue of depth, there is nothing behind that tree. I think the void is causing it. But it is something I have on my to-do list to investigate.

I'm currently hunting a bug on the trees, which I don't think you can see in that shot.

Take a look at this:

[click for 1920x1200]


The leaves there are just a white texture, as you can see in the colour buffer. For some reason the grass behind the tree leaves is peering through. It's an ugly effect. This is a higher priority for me to fix right now. It actually does something similar in modelview, so I'm not entirely convinced it's a bug in my system.
Logged

-...-

Shadowsong
Customers
Community Member
*****
Posts: 328


« Reply #27 on: November 13, 2009, 05:24:08 AM »

Ah sorry guess I just had one of your demos in mind were you said you were not using MRT (just TVTextures instead??), so this is where my question came from. No idea why I wrote "true", though Cheesy

Well yeah that is some bad bug. Don't know if anyone has seen this in modelview before but if then Sylvain or Shadow should have a look at this...

Haha looks like you accidentally created some magical way to have semi-transparency in your deffered renderer Wink  Grin
Logged
AriusEso
Customers
Community Member
*****
Posts: 940

Esoteric


« Reply #28 on: November 13, 2009, 05:36:00 AM »

Well, I don't think it's a TV bug. I just ran this test:


[click for 1920x1200]


The alpha on the cubes works fine. So I'm left thinking the tree mesh itself has some weird issue. I will see if Sylv is curious enough to take a look later.
Logged

-...-

Shadowsong
Customers
Community Member
*****
Posts: 328


« Reply #29 on: November 13, 2009, 05:46:56 AM »

May I ask: how do you handle the transparency?
Do you have to render them forward? And how exatecly do you combine that with your deferred-rendered output picture?

Looks like all those things are transparent, the cube, the bushes, the tree's leaves...
Logged
AriusEso
Customers
Community Member
*****
Posts: 940

Esoteric


« Reply #30 on: November 13, 2009, 05:51:25 AM »

May I ask: how do you handle the transparency?
Do you have to render them forward? And how exatecly do you combine that with your deferred-rendered output picture?

Looks like all those things are transparent, the cube, the bushes, the tree's leaves...

Well, you should notice that they are not semi-transparent things. I use the, rather expensive, clip() intrinsic. The light markers/balls are rendered in forward and are only a debug thing. I clear the depth buffer, so I handle the light markers depth myself in a shader doing a comparison -- this keeps them in the right place visually and allows them to be occluded by the deferred geometry.

By the way, I added a giant sphere around the landscape and the white edge does indeed vanish so it is obviously some weird depth/void thing.

Edit:

clip() -- http://msdn.microsoft.com/en-us/library/ee418281(VS.85).aspx

Code:
clip(tex2D(csample, v2fin.uv).a - fUserClip);
« Last Edit: November 13, 2009, 05:57:32 AM by AriusEso » Logged

-...-

Shadowsong
Customers
Community Member
*****
Posts: 328


« Reply #31 on: November 13, 2009, 06:07:26 AM »

Ah I see, this is a very straightforward solution to have deffered tranparency. Well, the performance costs of the clip()-ing can't be too much if you are using it on so many grass meshes, is it?

Also forward rendering any semi-transparent stuff might not be the problem, but then againg those things can't be lit by all the "deferred" lights so this may look weird in some situations.
The most major problem I can think of are particles. Almost any particle system, starting with smoke, uses semi-transparent sprites for smooth edges. So particles have to be rendered forward which makes them incapable of being lit properly by all the lights. Hm any ideas?

Ha so that void problem was easy to fix Wink
Logged
AriusEso
Customers
Community Member
*****
Posts: 940

Esoteric


« Reply #32 on: November 13, 2009, 06:15:29 AM »

The most major problem I can think of are particles. Almost any particle system, starting with smoke, uses semi-transparent sprites for smooth edges. So particles have to be rendered forward which makes them incapable of being lit properly by all the lights. Hm any ideas?

Yes, that's exactly right and why I intend to leave them till last. Although, it has to be said. TV3D doesn't light it's particles in forward anyway. I'm not entirely sure yet how I am going to light them. It's a problem I've tried to ignore in my brain otherwise it will make me cry. I'm sure I'll think of something. They'll also be z-feathered( see my earlier work: http://www.truevision3d.com/forums/indevelopment/zfeathering_aka_soft_particles-t18708.0.html ) and on PhysX capable GPU's physics controlled. I will more than likely be creating my own system as they'll need to be able to work as smoke, fluids( very keen on doing some decent physics based blood splatter demo's ).

Edit:

It may be possible to create some sort of post-deferred and light buffer and do it that way. That would work, but it might be too much overhead.
Logged

-...-

AriusEso
Customers
Community Member
*****
Posts: 940

Esoteric


« Reply #33 on: November 13, 2009, 06:55:17 AM »

Added now for the debug display a sphere of influence on the lights. So we can see also that.

[click for 1920x1200]
Logged

-...-

AriusEso
Customers
Community Member
*****
Posts: 940

Esoteric


« Reply #34 on: November 13, 2009, 07:11:19 AM »

Just for giggles.  Grin

[click for 1920x1200]


Logged

-...-

Shadowsong
Customers
Community Member
*****
Posts: 328


« Reply #35 on: November 13, 2009, 07:21:38 AM »

Daaaamn someone took to much LSD Grin

While thinking about the transparency problem and browsing through your deffered rendering tutorial, I found that paper about inferred lighting and am reading it with interest. Have you ever thought about using that? It seems to fix the transpareny issue as well as some other things like AA.
Logged
AriusEso
Customers
Community Member
*****
Posts: 940

Esoteric


« Reply #36 on: November 13, 2009, 07:25:22 AM »

Daaaamn someone took to much LSD Grin

While thinking about the transparency problem and browsing through your deffered rendering tutorial, I found that paper about inferred lighting and am reading it with interest. Have you ever thought about using that? It seems to fix the transpareny issue as well as some other things like AA.

I haven't read the paper yet. The thing is, I don't want to make any heavy modifications to mako's core.
Logged

-...-

Shadowsong
Customers
Community Member
*****
Posts: 328


« Reply #37 on: November 13, 2009, 08:42:05 AM »

Hm I'm not quite sure about this Inferred Lighting. It seems like it is not just and advanced deferred solution but something with it's own advantages/disadvantages. It seems like it may be problematic with lots of objects onscreen because they store object IDs in an 8bit buffer, so more than 256 objects may cause artifacts. Also they say this algorithm might be slower in comparison for scenes with only few lights.

And they don't really fix the transparency problem, though they have a neat workaround:
They are using a buffer with a smaller resolution than the output image. They are using Discontinuity Sensitive Filtering to somewhat re-create the high resolution for the output image. Now comes the trick: by applying a stipple pattern to any semi-transparent objects, this DS-Filtering algorithm somewhat blurrs the semi-transparent mesh with anything that shines trough the stipples. This way, having a 2x2 stipple, your mesh becomes 50% transparent.

While this is a crazy workaround, it can't be used to create real continuous transparency like fading out smooth edges or such. You can only have 3 different levels of transparency which is quite a limit. So no, they didn't fix the particle-transparency problem.

Also, having a smaller resolution on the buffer may cause less detailed normalmapping effects.

So I guess I'd go with deferred lighting, though this inferred idea is amazingly interesting.
« Last Edit: November 13, 2009, 08:44:11 AM by Shadowsong » Logged
AriusEso
Customers
Community Member
*****
Posts: 940

Esoteric


« Reply #38 on: November 13, 2009, 01:43:17 PM »

Yea, I'm sure I can find a solution for the particles. If not, rendering them without lights wouldn't be overly stupid -- as I said, TV3D and many other engines do this anyway. I would like lighting on them however. Mako currently has 3 levels of quality, I could easily make it so that lower end systems don't have lit particles and higher end systems do. I think rendering the lights as some kind of projection map and using them as a basis for lighting them in forward would work. The issue is the background, seen through the semi-transparency, but this could be a simple blit from the main buffer once the deferred scene is rendered. I'd really have to test it to see how slow/quick it is.
Logged

-...-

AriusEso
Customers
Community Member
*****
Posts: 940

Esoteric


« Reply #39 on: November 14, 2009, 01:24:48 AM »

Question about material systems.

One assumes for this I just store colours in a buffer that denote materials. As such I intend to have 8 or so base material types with different variables to customize them. I want to include a few different specular models. What materials would people like to see implemented, I can't promise I'll include every suggestion, but I will certainly consider each. So please list your wants here.

Thanks.
Logged

-...-

Pages: 1 [2] 3 4 ... 6
  Print  
 
Jump to:  

Powered by SMF 1.1.3 | SMF © 2006-2007, Simple Machines LLC
Seo4Smf v0.2 © Webmaster's Talks