QuadMesh casts no shadow with ShadowedRenderPass

Hello,



Today I came across out a quirky feature of the ShadowedRenderPass, whilst trying to figure out why a model created in Blender3D and exported with the Hottbj exporter cast no shadow.

After ruling out the causes I knew of and those found on this forum I ended up stepping through the JME code, I came across the culprit, it was where the ShadowedRenderPass gets the occluder meshes



[pre]  protected void setupOccluderMeshes(Spatial spat) {

      if (spat instanceof TriMesh)

          addOccluderMeshes((TriMesh)spat);

      else if (spat instanceof Node) {

          Node node = (Node)spat;

          for (int c = 0, nQ = node.getQuantity(); c < nQ; c++) {

              Spatial child = node.getChild©;

              setupOccluderMeshes(child);

          }

      }

  }[/pre]

As you can see from the code, unless the mesh is a TriMesh it will not be included in the Occluder meshes, so will not cast a shadow.



The blender model contained quads that were exported as QuadMesh elements. I tried converting all the faces from quads to triangles > Hottbj export  > load into JME == behold …shadows!



I didn't find any docs about the ShadowRenderPass working exclusively on TriMeshs, so this makes me wonder …does everyone here design models using triangles exclusively? or is that something the exporter takes care of? or is this quirk on a bug fix list?

I regret that I have no solution to this problem… but this is a problem for me as well.



Is there no support for QuadMeshes or do I have to convert everything to a TriMesh?  I really don't want to have to do that…

QuadMesh is really a mess! Not well supported… shadow, collision,…



Nevertheless if you are in blender convert all Quad to triangles (select all faces and hit ctrl-t) Then export

again… if you are not in blender… have fun :smiley:

Yeah I agree I'm going to have to try that… as a modeler though I don't like converting things from quads to triangles as it tends to make the smooth shading less attractive. No big deal though. What is annoying is that I was debugging my code (assuming I wasn't doing something right in my test app) for 2 days before I came across this thread and realized that it was the setupOccluderMeshes method that was failing to warn in the case of a Spatial that is not a TriMesh.



I don't think it's good practice to have a recursive function's base case be dependent on class type. There should be a warning for leaf nodes that are not TriMeshes.

Robgfx, the rendering of the quad mesh is supported …as for anything else though, it's anyone's guess (in JME2 shadows with ShadowRenderPass definitely are not).



This problem was an extremely frustrating one for me. Mainly because I'd assumed that all parts of the core jme package were sound, so obviously couldn't possibly be at fault  :-o

Ideally, the QuadMesh class should be taken out since video cards and collision algorithms prefer everything as triangles. Quads have been deprecated in OpenGL3.0 and DirectX10.