Dual-Sphere Unfolding

[Kjell]

Very neat omni-directional mapping approach. Has a little more "warping" then the regular dual-paraboloid, but only requires a single pass!

http://www.youtube.com/watch?v=WnNOMTDmYTg

K

[jph_wacheski]

This looks great, well apart from the shadows being rather pixelated, however that seems to be sort of standard in many real-time settings (PS3 games are often awful in this way). I did recently see this and wonder how he achieves such smooth shadows in a real-time setup. [ http://www.quayola.com/soundvisualisation/partitura/ ]

ZGE desperately needs lighting w/ shadows. I have no idea how to write such a glsl shader or set it up to work in the engine. Nor do I particularly want to know (I don't want to build an engine, just make interesting stuff using an engine). I would like to simply turn the lighting on in the editor, and set up the parameters for the scene or lighting situation. Perhaps we need a set of standard lighting shaders to this end?

[Kjell]

Hi jph,

This looks great, well apart from the shadows being rather pixelated, however that seems to be sort of standard in many real-time settings (PS3 games are often awful in this way).

That's one of the reasons I've always been in favor of stencil-based shadows, although they have their downsides as well ( can be quite slow to compute ).

I did recently see this and wonder how he achieves such smooth shadows in a real-time setup.

Wonderful visualizations Concerning those shadows; because the camera is static you can do a very "tight" shadow map, giving you the best resolution / result possible.

ZGE desperately need lighting w/ shadows. I have no idea how to write such a glsl shader or set it up to work in the engine. Nor do I particularly want to know (I don't want to build an engine, just make interesting stuff using an engine). I would like to simply turn the lighting on in the editor, and set up the parameters for the scene or lighting situation. Perhaps we need a set of standard lighting shaders to this end?

Agreed, it's too complicated right now. Personally, I'd just go with the light functionality build-in OpenGL, but as quoted ..

A light component is slightly more problematic as it would use OpenGL built-in lighting model but this is deprecated as of GL 3+/ES. And I would rather not introduce more deprecated GL-calls until we have decided a path to the newer GL-models.

.. Ville doesn't agree

K

[VilleK]

We can add light component because GL3 render modes probably need a lot of careful consideration and we need something sooner, I can agree on that.

But what about shadows? It seems like such a huge topic and I always shy away from the complexity each time I read an article about it. Kjell do you know of an shadow algorithm that gives "nice enough" result and isn't ridiculously difficult to implement?

[StevenM]

I found the NEHE Productions stencil buffer shadow example works well.

http://nehe.gamedev.net/tutorial/shadows/16010/


I was able to get the exact example working very easily by practically wrapping the entire code in a DLL - at least I know it works

The key to getting a shadow system going in zge is the definition of the object structures.

the example I have working in zge reads a text file that look like this:

Code: Select all

24
-2  0.2 -0.2
 2  0.2 -0.2
 2  0.2  0.2
-2  0.2  0.2
-2 -0.2 -0.2
 2 -0.2 -0.2
 2 -0.2  0.2
-2 -0.2  0.2

-0.2  2 -0.2
 0.2  2 -0.2
 0.2  2  0.2
-0.2  2  0.2
-0.2 -2 -0.2
 0.2 -2 -0.2
 0.2 -2  0.2
-0.2 -2  0.2

-0.2  0.2 -2
 0.2  0.2 -2
 0.2  0.2  2
-0.2  0.2  2
-0.2 -0.2 -2
 0.2 -0.2 -2
 0.2 -0.2  2
-0.2 -0.2  2

36
1 3 2 0 1 0 0 1 0 0 1 0
1 4 3 0 1 0 0 1 0 0 1 0
5 6 7 0 -1 0 0 -1 0 0 -1 0
5 7 8 0 -1 0 0 -1 0 0 -1 0
5 4 1 -1 0 0 -1 0 0 -1 0 0
5 8 4 -1 0 0 -1 0 0 -1 0 0
3 6 2 1 0 0 1 0 0 1 0 0
3 7 6 1 0 0 1 0 0 1 0 0
5 1 2 0 0 -1 0 0 -1 0 0 -1
5 2 6 0 0 -1 0 0 -1 0 0 -1
3 4 8 0 0 1 0 0 1 0 0 1
3 8 7 0 0 1 0 0 1 0 0 1

9 11 10 0 1 0 0 1 0 0 1 0
9 12 11 0 1 0 0 1 0 0 1 0
13 14 15 0 -1 0 0 -1 0 0 -1 0
13 15 16 0 -1 0 0 -1 0 0 -1 0
13 12 9 -1 0 0 -1 0 0 -1 0 0
13 16 12 -1 0 0 -1 0 0 -1 0 0
11 14 10 1 0 0 1 0 0 1 0 0
11 15 14 1 0 0 1 0 0 1 0 0
13 9 10 0 0 -1 0 0 -1 0 0 -1
13 10 14 0 0 -1 0 0 -1 0 0 -1
11 12 16 0 0 1 0 0 1 0 0 1
11 16 15 0 0 1 0 0 1 0 0 1

17 19 18 0 1 0 0 1 0 0 1 0
17 20 19 0 1 0 0 1 0 0 1 0
21 22 23 0 -1 0 0 -1 0 0 -1 0
21 23 24 0 -1 0 0 -1 0 0 -1 0
21 20 17 -1 0 0 -1 0 0 -1 0 0
21 24 20 -1 0 0 -1 0 0 -1 0 0
19 22 18 1 0 0 1 0 0 1 0 0
19 23 22 1 0 0 1 0 0 1 0 0
21 17 18 0 0 -1 0 0 -1 0 0 -1
21 18 22 0 0 -1 0 0 -1 0 0 -1
19 20 24 0 0 1 0 0 1 0 0 1
19 24 23 0 0 1 0 0 1 0 0 1

All I need is a way to extract and store data like this in an array or two within zge, and It could be a working system.

The data is explained as -

The vertex normals are used to calculate the orientation of the face in 3D space, so you can determine which are facing the light source when casting the shadows.

The plane equation describes the plane that this triangle lies in, in 3D space.

The neighbour indices are indices into the array of faces in the object. This allows you to specify which face joins this face at each edge of the triangle.

The visible parameter is used to specify whether the face is "visible" to the light source which is casting the shadows.

However - the act of generating this data was not explained at all - it was suppose to be implicit - but it's not for me. Mesh Expression? Read it from a 3ds file?

[Kjell]

Hi Steven,

I was able to get the exact example working very easily by practically wrapping the entire code in a DLL - at least I know it works

Did you destroy the window context and created a new one that does explicitly request a stencil buffer? Otherwise it won't work on all systems ( just like the Accumulation Buffer ).

And you might want to take a look at GL_POLYGON_OFFSET_FILL instead of using "baked" data

K

[StevenM]

Thanks for the tips Kjell - I'll look into the things you mentioned later -

If I can't figure out a way to generate data structures for objects first - It will never work anyway.

so far, All I did was split the code up in too two big procedures. A side from that - It is an exact clone of the example.

The first part is called onloaded - just reads and stores the object data.

the second part calculates and draws the scene on render.

What I'd like too do is break it down in to smaller functions, so it can be made more flexible to work with any scene. Should be practical beyond just shadows too. So even if the realtime shadows won't work... I already created the functions for adding/removing lights with position, diffuse,ambient, specular,emission color properties too. That, in itself, was an important to have to get this example working.

EDIT: I also want to remove all the stuff that can simply be done with the opengl function calls in ZGE too - no need to include that in the DLL.

[Kjell]

Ah,

You're stuck on that already The thing is that the build-in mesh components don't play nicely with the stencil shadow idea. So, ( as you mentioned ) you need to either pull the data from a mesh into a bunch of arrays, or use your own importer.

Now, personally I've stopped using the build-in Mesh components quite some time ago, but you have to question yourself if this is a road you want to take. Doing shadow-map based shadows is a much better fit for ZGE, and can be done entirely using components ( no OpenGL calls necessary ). But in case you do want to go down the rabbit hole, let me know .. I could whip up a simple shadow volume generation example.

K

[StevenM]

Doing shadow-map based shadows is a much better fit for ZGE, and can be done entirely using components ( no OpenGL calls necessary ).

I didn't even consider shadow maps - mostly because for some reason I just didn't they worked in real time with animation - but if it's an option that is fast enough - I'll look into.

I'll keep working on the stencil buffer too though - I like the speed - and it seem pretty popular in a lot of other game engines.

[Kjell]

You probably mean the other way around. Stencil shadows are notoriously slow to compute / render .. and apart from Doom 3 I don't know any "recent" games that use them.

Anyway, attached is a easy to understand but highly unoptimized example on calculating a shadow volume based on the standard mesh format. All logic is in the Model.OnRender node, so you can preview the entire thing by locking on the Model and enabling "Update Time". And normally you'd render this to the stencil buffer of course ..

K

[StevenM]

Awesome - thanks - this example is a really helpful...much easier to understand How these shadow volumes are generated and relate to the light source now.

I'll certainly take a closer look at shadow mapping. Not being familiar with realtime shadow techniques - I confused the whole concept of shadow maps with "deep" shadows maps that I use in my 3d applications.

[VilleK]

I will read up on the literature I've got on shadow techniques and evaluate different options here.
Don't burn yourself out Steven . I'm convinced shadows are needed in ZGE, we just need to find the best suited technique.

Now, personally I've stopped using the build-in Mesh components quite some time ago

Kjell you've always had your own ways of doing things . You mean you only use direct opengl-calls instead? Good for experimentations I guess but what about high-poly models? And what do you consider to be the main weaknesses of the Mesh-components?

[Kjell]

Hej ~

You mean you only use direct opengl-calls instead? Good for experimentations I guess but what about high-poly models?

Yea, for static meshes i use display lists ( deprecated, i know ) .. which have similar performance as static VBOs.

And what do you consider to be the main weaknesses of the Mesh-components?

They are fine for what they are, but regarding stencil volumes .. if you for example only want to extrude¹ the faces that are facing a light ( which is a common optimization ), when using a Mesh component there's no way to get rid of the faces ( and vertices ) that don't² Of course these days a streaming element buffer, or a geometry shader might be even better ..

¹ Obviously there's no MeshExtrude component either.
² Unless you pre-calculate + recreate the mesh by loading individual triangles in a loop and positioning them accordingly, but that's just silly.

K

[StevenM]

I will read up on the literature I've got on shadow techniques and evaluate different options here.
Don't burn yourself out Steven . I'm convinced shadows are needed in ZGE, we just need to find the best suited technique.

Ok - thanks for heads up - I'll try not to get too worked up. Shadows seem to be one of the most difficult problems with OpenGL. I've seen a lot people venting frustration about it in other forums. Shame though - shadows are so essential. This is something that the Khronos Group should have addressed long ago.