Irrlicht 1.8 beta phase

[hendu]

That patch would regress opengl, it'd be worse after the patch than before. Null and DX are improved though.

[hybrid]

Yes, but I'd have to check the sw renderers as well, as they might not work with vertex primitive list calls that way, etc. So not really what I need right now. Still, I really like the patch and addition, so I would prefer to have it stored properly.

[christianclavet]

Hi,

Got theses to report, tested from SVN release 4344 (oct 30 2012):

Exemple 26 (occlusion query) is crashing and giving me this in the console.
EDIT: I did not clean the solution before. Thanks Hybrid.

Output on the console:
Irrlicht Engine version 1.8.0-alpha
Microsoft Windows 7 Home Premium Edition Service Pack 1 (Build 7601)
Using renderer: OpenGL 4.2.0
GeForce GTX 460/PCIe/SSE2: NVIDIA Corporation
OpenGL driver version is 1.2 or better.
GLSL version: 4.2
Resizing window (640 480)
Could not open file of texture: #colorring

Example 8 Special FX seem to have problem with the shadow. The object seem to have "holes" in the shadow. Perhaps the mesh that doesn't have all their vertices welded properly:


The demo seem to have changed. I do not see the "smoke" FX now when I shoot the wall. There doesn't seem to be a visible collision as before...
The shadow is still problematic: The shadow projection is almost correct except that I see a "attached line" that connect to something small that moving on the ground. If I move the camera this small object move also with the camera (rendered in view space?) The rest of the shadow does not move and look solid with the ground.


These tests have been done on my main PC (Windows 7 with a NVidia GeForce GTX460 video card). The results are the same in OPENGL and DIRECTX 9.0

[Mel]

I had the same results on my GeForce 8500 GT WinXP 32 bits and on my Nvidia 425 M Win7 64 bits. Particles disappearing, and bad shadow rendering.

[hybrid]

Particle disappearing should be fixed since a few weeks in trunk already, have to test again. The ESP error is usually due to a non-cleaned recompile.
The shadow changes are something that we are still working on. The wholes are probably due to some faces missing in the shadow volume mesh. I guess we have to switch to indexed geometry next time, which would also allow for better VBO usage. Sydney has this strange artifact, but we couldn't find a reason except for a whole in the mesh somewhere.

[christianclavet]

Hi, Confirmed for example 26 occlussion Query. After cleaning the solution it run ok now. Sorry.

I loaded Sydned in 3DS Max and checked the vertices near the hand (where I see the shadow breaking apart):
- The problem look like the hand was "capped" and the modeler added the hand over it.

I removed the hand and look:


Theses 3 polys should not be there if there is a hand. So perhaps the rendering of theses 3 faces in the shadows are cause of the problem.

Edit: THAT WAS IT! The problem is in both hands! I used my "conversion" tool Fragmotion and removed the faces from the 2 hands and tested the demo again. Result: No shadow breaking now.

Here is my corrected Sydned (less 6 polygons):
http://www.clavet.org/files/images/irrlicht/sydney.md2

Note: I forgot to mention that when I get in fullscreen mode and exit in the DEMO that my screen is set at 800x600 (same as the demo), it's not going back the resolution it was before I launched the demo.

Edit2: I checked the dwarf, and the head is another model that is "planted" over the body model. Some polygons are hidden under the heads (the probable cause of the "holes" near the head.) Vertices seem Ok to me (there doesnt seem to have duplicate vertices)

[Mel]

And with other models?

[Nadro]

@christianclavet
At first thanks for checked and improved these models (I already uploaded it on SVN) But I have also a question for this resolution bug after exit. Which operation system and irrlicht video driver You used?

[christianclavet]

Hi, I've not tested all the models. But for the moment, I know that the shadow system will fail if a shape have another one attached on it (As the hand at the end of an capped arm). As for the Dwarf, I think we see "projected" holes, because the head is not attached to the body but placed there. (Faces are not connected).

If you can for the Sydney model, keep both models. Perhaps you can find a technical solution that would work in theses circumstances (Convex/Concave thing?). At least now, if we see this shadow leaking again, I think we could explain it.

For the test of the demo and the problem with the resolution, I was testing under Win7 and OpenGL. (Resolution bug)

[fmx]

this solution is only temporary and will cause problems for many people later
you need to modify the occlusion/shadow-cast calculation to take into account multiple (overlapping) tris, instead of only first outermost tri on surface

[hybrid]

Particle problem in Demo is fixed, the usual fix was indeed still missing there. Somehow,the old particle blending somehow worked with full transparent vertices, but now fully transparent particles are just that: Fully transparent. So the particles were still there, but invisible.
The shadow stuff will be improved for 1.8.1, so I guess we can live with some limitations as long as the basic shadow works.
I will discuss the fullscreen problems with OpenGL with Nadro and then we should be ready for release.

[Nadro]

This is one of the common requirment in Shadow Volumes to use properly - closed meshes (without wrong faces etc), thats why I think we shouldn't do any workaround in an Irrlicht to improve an 3d modeller faults. Optionally we can add to an IMeshManipulator method like "createMeshForShadowVolumes", because we shouldn't add this directly in shadow volumes system. Preprocessed mesh is better in this situation because it will be not slowdown a shadow rendering and will be not too problematic in implementation (eg. in vertex shader we can't remove tris etc).

[hendu]

Actually you can remove tris in vertex shader, by outputting a degenerate one. (zero area tri)

[Nadro]

Shift simple vertex to infinity is possible (w = 0), but You can't disconnect this vertex from others. As I know without geometry shaders, where we have an access to primitives it isn't possible to do it.

[hendu]

If you move the three verts to the same position, the tri they surround will become degenerate and be culled.

Sure, you then need to recognize which three verts of course But it's quite possible still.