Hanging in updateShadowVolumes - 1.8

[robmar]

For a test case just run the TKOcean demo that´s available on this site, and load a 1 MB mesh, say made of 16 text characters (use Blender text entry and export mesh as .3DS), and enable shadows.

By the way, under 1.8 GetTexture seems to be returning with iReferenceCounted 1 higher than under 1.7.3. Is there any reason?

[hybrid]

In case you use OpenGL then yes, we added an internal grabbing of the textures inside the driver.

[CuteAlien]

Sorry, I don't know TKOcean demo - and if by "this site" you mean Irrlicht's homepage then I just don't see it so far. When googling it the result returns this thread....

[robmar]

Its here http://irrlicht.sourceforge.net/forum/v ... hp?t=35170

[robmar]

@Hybrid, So why did you add an internal grab under opengl? Where was it added?

[hybrid]

Just check the forum or the SVN. It was introduced in the internal activated texture cache. And it's there because the driver requires the texture to exist while it is bound.

[robmar]

Was it related to the GL errors that sometimes occur after unlocking textures?

[robmar]

Does anyone know how to revert 1.8 shadow to 1.7.3 mode, if thats possible without too much work?

[hybrid]

Well, these shadows were simply wrong. They looked somewhat ok in some situations, but the shadow positions and dimensions were not correct in any way. So better don't do it. Otherwise simply replace the shadow scene node files from 1.7.x

[robmar]

Yes but.... with 1.8 they may be correctly calculated, but with the larger meshes, the calculateAdjacency routine is being called and it hangs everything for a couple of minutes while it iterates all the surfaces, and that just isn´t viable for anything but simple-object games.

I haven´t been through the shadow code, so can you tell me if the call the calc.adjacency can be skipped and still get reasonably accurage shadows under the 1.8 method?

[CuteAlien]

Replacing the whole file like Hybrid proposed is probably the easiest solution. I wouldn't expect skipping the adjacency calculation to work.

[robmar]

okay but what i mean is this: Is it possible to avoid the adjacency caluclation as 1.7.3 shadows does, in 1.8 shadows, and still have it work? Can the person that did the shadow code, the new one, answer?

Because then the 1.8 shadow improvement could be used.

As it is, 1.8 shadows aren´t viable for anything more than simple real-time 3D

[hybrid]

The old version of the shadow rendering didn't care for the silhouette and rendered a shadow volume for all faces IIRC. This works, but also produces strange artifacts in some cases. The major problem with this is though that it has a huge render penalty, because stencil rendering is slow anyway, and the fillrate was flooded with a huge number of useless rendering. The new system avoids all these extra faces, which are not required anyway. This has a one-time penalty at shadow creation, but is faster with typical meshes (e.g. the dwarf we use in the example).
Another major flaw with the old shadow system was the wrong light projection of the shadow volume. Thus, the shadow appears at wrong places and is sometime not connected to the mesh body as it should be.

[robmar]

So... there is a need for a faster method to check the faces, without the loop in a loop that compares every face with all other faces.

... there has to be a better way to do this using the GPU hardware

[hybrid]

Yes and yes. Anyway, the current solution is also better than the old one, because it trades a general slowdown with a one-time calculation.