DeleD Community Edition

[Mille]

I'm still new to Delgine, anyway I'm coding a scene partition algorithm for a .dmf level and came across the following question:

I’ve looked at a few .dmf files, and it seems that each object has a unique material ID. Is
this always the case ? – I mean is it so, that when saving to .dmf the Delgine takes care of each object in such a way that it has one and only one material ?

Thanks ..

[Paul-Jan]

No. The material ID simply refers to the material in the material list, and is only unique if you actually have assigned a unique material to every object in the scene.

[Mille]

ok, makes sense – so it’s a matter of me making the scene “correctly”

Its just so, that the rendering will speed up if many triangles with the same texture(s) are rendered in on go!

[Paul-Jan]

Very true, but that is up to your rendering code. Simply sort your geometry data on texture or material (depending on wether you do multipass rendering or not) before sending it to the graphics card

[Mille]

Just got the geometry sorted with respect to the material, very nice - I can now render dmf maps Putting each dmf object into an Octree structure and the triangles will flow through the pipeline as quick-sand ...

Anyway, I was thinking about normal maps (bump maps). Dose Delgine support normal maps in the .dmf format ? - It would fit nicely into the material layer system.

I hope you guys never stop working on Delgine!, its cool stuff …

[Paul-Jan]

About the normal maps: Nope, it doesn't at the moment. We like the idea though, and already have some plans in that direction.

The point is, at this moment, all DeleD operations are supported by all hardware, for example falling back to multiple passes when multitexturing runs out of texture units. Adding support for normal maps is in that way quite a big step, as that would demand some minimal graphics card specs to run. Also, we'd like to spice up the texturing capabilities first, because you'd probably use normal maps most for detailmaps 'skinned' around the model.

Thanks for the positive feedback and compliments, very much appreciated

[Mille]

Ok I see your point, haven’t thought of it that way.

However, its not really a problem for me anyway, since the normal maps I use have the same texture coords (u,v) as the diffuse map. So I just calculate the famous tagent-binormal-normal matrix for each vertex to get per-pixel-lightning stuff rooling in the shaders (similarly to what doom3 dose).

But then again, the demos I make requires new hardware, otherwise it’s a bad eeg

[Jeroen]

[Mille]

Well, if we want to do per-pixel-lightning as seen in halflife2/doom3, then this is how its done: For each light source we have a light vector to each vertex. The light vectors has to be transformed from object space to tangent space (texture space), and this is done by matrix multiplication. The matrix we need is the TBN matrix for each vertex. In algebra the TBN is called a "basis" for each vertex.

In the standard lighting equation, we take the dot product between any normal on the surface and the light vector. The surface normal exists in tangent space while the light vector exists in object space. Therefore, in order for the dot product to make sense, we have to transform the light vector into tangent space by doing the TBN matrix multiplication. Hence, for each pixel we can take the dot between the normal (from the normal map) and the transformed light vector ... this is all best done in programmable shaders (Cg/HLSL)

I recall a few articles on gamedev.net on this normal map stuff.

Screenshots are on its way ... but I'm still new to the .dmf format, havn't parset light info yet

[Jeroen]

Thanks for the explanation! That's some cool stuff indeed!