mako ( deferred framework )

[AriusEso]

A couple weeks back I started to design a decent deferred framework for Meadow5 and some other things. It's starting to take shape so I figured I'd post up a few shots. This is all WIP stuff.


[click for 1920x1080]


The above screenshot is the current maximum composite. The HDRR can be disabled in the framework. I intend to add other things like SSAO and a film grain later. Each will have quality settings. The HDRR is still very much a work in progress. I started it 8-10 hours ago and the tone mapping code is placeholder. There is no 1x1 luminance gather.

The deferred system itself runs entirely on CTVMinimesh and the geometry buffer is an fp16 MRT. Even at 1920x1080 on a Mac Mini(NV9400M) I can push upwards of 30fps.

Currently geometry types added to the deferred system include CTVMesh, CTVLandscape, CTVMiniMesh and I've started on particles. I will add actors once I have particles completed.

It's very easy to add geometry and lighting to the backend.

Code:

m_Lighting->CreateLight(m_Camera->GetInternal()->GetPosition(), RGBA(1, 0.6f, 0.6f, 1), 50, true);

int IDNew = m_Geometry->LoadStatic("media\\zelda.tvm");
m_Geometry->SetStaticPosition(IDNew, m_Camera->GetInternal()->GetPosition());
m_Geometry->SetStaticScale(IDNew, Vector3(0.15f, 0.15f, 0.15f));
m_Geometry->SetStaticPhysics(IDNew, MAKO_DYNAMIC_BODY, 10);

All geometry types have Get() functions for their TV3D bases, as do things like the physics engine of course.

[click for 1920x1080]


The above screenshot shows CTVLandscape. I had it working with splatting by using a seperate colour buffer. However, I dropped this idea in favour of building my own texturing scheme into my terrain class. The idea is to make painting and sculpting easier.

The shots may look dark, the crap tone mapping is doing that. It's currently more placeholder than anything, I am going to add luminosity, auto-exposure and blue shifts.

[click for 1920x1080]


Minimesh, I consider this slow. I'm going to take a look at Zak's increased constants stuff. I tried to get hardware instancing working, but alas, epic fail.

Code:

makoParticles(45% complete. Still working on semi-transparency and I have to add quality settings for z-feathering.).

makoBoned(0%, skinned geometry.).

makoShadows(Design stage. Combination of static and dynamic mapping, cubic and directional. Low, Medium and High qualities. Shadow culling.).

makoTerrain(10% complete. Need to add painting and sculpting features.).

makoNature(Design stage. Ponds, Lakes, Oceans. Fog, Sky, Rain, Snow, Sleet, Wind.)

makoFog(Design stage. Volumetric and traditional.).

makoPortal(Design stage. Portal visibility culling.).

GeomBuffer(Need to add depth and material id passes.).

All Geom(Need to add material pixel code -- plastic, metal, skin etc etc.).

makoFSM(Finite State Machine for simple AI).

There are other things. I'll add as I go.

[rootsage]

Wow, this is looking very cool. I was thinking of adding a deferred system to this editor I am working on. Good work, I am certainly going to be watching this thread

[AriusEso]

Started working on horizon-based SSAO. As you can see it currently has severe artifacts, this is of course without blurring.

[ZaPPZion]

Nice to see some work of you again

[AriusEso]

Nice to see some work of you again

---------

[click for 1920x1080]


The cubes are all physics controlled minimesh. I will upload a video shortly. Ignore the crap shadows please.

[Raul]

OMFG. . You should be arrested.

[AriusEso]

OMFG. . You should be arrested.

rofl, I only reside in cells when I'm told to "sleep it off".

Here is the video, click the HD button for 1280x720: http://www.youtube.com/watch?v=E_NASpV5u7A

[ZaPPZion]

Woa, that's a lot of boxes!
But what is the use of doing this on minimeshes if you're using boxes? i mean, the rendering will be fast, but the physics simulation will take the same amount of time, right ?

[Zaknafein]

The last shots with like a million boxes are amazing. Very cool.

[AriusEso]

Woa, that's a lot of boxes!
But what is the use of doing this on minimeshes if you're using boxes? i mean, the rendering will be fast, but the physics simulation will take the same amount of time, right ?

Physics is the same yes. But, reducing draw calls is always a good thing.

[AriusEso]

The last shots with like a million boxes are amazing. Very cool.

Yes sir. I intend to implement your approach to constants based instancing in the near future. This should provide a decent speed boost. Aswell as using SetMatrixArray() instead of SetMatrix(). I intend to get soft bodies, cloth and fluids done by this time next week -- that might be optimistic though. The PhysX documentation is seriously bad, half of it is dated 2004/2005 and not only irrelelevant but also not even NVIDIA but the original Ageia(sp). But anyway; enough ranting about crap docs lest this turn in to a "why no 6.5 docs" thread , but yea, I want the fluid/smoke/gas( my main reason is to enhance blood splatter for a project I've been planning these past 2 years, more on that much MUCH later ) mostly and CTVMiniMesh should be great at reducing the rendering load. I also need to work out decent but less visual CPU equivelents(sp).

Although, it should be noted. This is not rendered by Mako. It's all test code at the moment. I posted it here because the testing is just as important as the implementation in my opinion. I have to understand how it works in order to make a cohesive and flexible API for my framework. Newton has pissed me off for so long and I've been meaning to take a look at PhysX. I got my new dev system on Wednesday, which so far has been epic - beyond what I expected it to be, that I finally took the plunge into PhysX. Mako will be a bit more advanced but will also allow CPU based scaled simulation. So those with the high-end NVIDIA GPU's can enjoy the benefits, those without will get a workable but less impressive alternative. I'm thinking mostly about Meadow5. However, I do also intend to wrap mako into a managed wrapper when it is complete and I'm satisfied with its performance and rendering quality. This entire project is outlined for about a year, so it's going to take a while, but I hope to put up some quality posts in terms of design and techniques -- I haven't yet because I'm still tinkering at the edges and writing design.

( sorry for spelling and grammar, been a good 36 hours since I slept )

[Zaknafein]

A note on my approach to instancing... It's mostly beneficial because you limit the subset of information each instance has. In Fez and my octree example, I only want position and a Y rotation, which fits in a float4. That allows 250+ instances per batch.
If you want free rotation, your best bet is a quaternion and a position, instead of a 4x4 transformation matrix... but you'd have to rebuild the matrix in the vertex shader. I'm not sure how much faster it would end up being.

Good luck with that anyway, it's good stuff.

[AriusEso]

I think that approach would work well in a grass/leaves example. I used cubes there because it demonstrates standard physics, I was going to throw in spheres and cylinders also. But for example, windy grass/leaves where the rotation relies on Y only. What do you think then in terms of performance benefit?

[Zaknafein]

If you send the Y rotation as a float (radians), you can reconstruct a rotation matrix using a sincos in the vertex shader and it's pretty fast. That's what I did in Fez and in the octree demo, and the huge amount of instances per batch easily compensates for the additional VS complexity.

[AriusEso]

I will certainly take a look at that approach, anything that makes the rendering of MiniMesh faster is a bonus in my book. An I appreciate you, as always, giving me advice. First though I have cloth and fluids to worry about lol.

[AriusEso]

Added some new bump mapping. This has inter-bump occlusion and shadowing.

[click for 1920x1080]


That's a 2-tri plane.

[ZaPPZion]

LOL WHAT 
That's quite incredible, really good to see this, makes me anxious to get back to 3d development 

[Raul]

I can't believe it's real...

[ZaPPZion]

I just saw something that's definately not real, but i didn't notice it at first, because i was so impressed 

[img=http://img401.imageshack.us/img401/1209/captureko.jpg]

How can there be holes in the shadows?

[AriusEso]

It is real, it's heavily based on the DXSDK Parallax Occlusion Mapping sample.

http://en.wikipedia.org/wiki/Parallax_occlusion_mapping

http://msdn.microsoft.com/en-us/library/bb147254%28VS.85%29.aspx

The shadow is off because it's based purely on texture sampling and parallax by it's nature offsets UV co-ords.