A few suggestions for JME 2.0 (Channels and PSSM)

First of all: I couldn't find the JME 2.0 wiki to check if i'm being redundant, sorry. Can someone put a link in the main wiki page please?


  1. Separation of concerns:

    Think of that like having 4 channels of information:
  • Channel 1: The data library, where the files are loaded and stored
  • Channel 2: The presentation channel, the OpenGL thread, the render passes, etc
  • Channel 3: The lightining mask channel, simplified geometries could be used as "masks" to generated the shadows
  • Channel 4: The collision mask channel, the same as above but for the collision/physics systems



    The simplest case would be when all channels use the same geometry from the "data library", and the more refined would be using a diferent geometry for every channel.



    A mask could be a collection of simple geometric volumes or a low-poly mesh.


  1. And the second suggestion (if I find some time I’ll try to port it to jme):

    PSSM - Parallel Split Shadow Map

    http://appsrv.cse.cuhk.edu.hk/~fzhang/pssm_vrcia/



    This is a very nice shadowing solution, can be hardware accelerated and is well scalable.



    That’s it for now.

    Cheers

I don't really understand the channels part, could you elaborate on that? What exactly is it's purpose and how does it work in the code?

Well the channels thing doesn't seem a bad idea to me. However, doing so at jME core level would imply that we must for example use the physics channel for physics.



That doesn't fit jME architecture where jmePhysics nicely works as an add on. The same applies to lighting, where you could be using a custom lighting solution or a custom pass for whatever the reason.



Such an architecture would be nice if current tools could export and manage channels. However people is using a bunch of different modeling applications which can't probably not manage, nor export channels in a common format.



Also, some people could need specific solutions to build up channel data. Some may post process their geometry to automatically generate LOD levels, and may wish to use those reduced poly models for physics or lighting. So channels should allow people to manipulate them.



So in the end you would need to manually select what geometry you are using for each thing. This means loading and setting up physic objects with the data you choose, doing the same for lighting, etc…



Actually, you can achieve something similar using several Nodes acting as root nodes for the different needs. Forcing people to use that "channel" architecture or adding it to jME will hardly improve usability or performance. Every 3D application usually has very specific requirements and performs different tricks that involve moving and manipulating data along systems (physics, 3D, lighting). Some subsystems, like continious terrain, shaders, volume shadows to name some would be difficult to integrate seamlessly with jME or any 3D engine that clasified geometry in 4 separate layers like this.



Moreover, you actually have that kind of separation. Physic nodes can have different geometry than what is seen, and same applies to other techniques where you can easily swap or disable nodes at your will.



While I can see your point for certain applications, I think that kind of architecture should be added to your own engine on top of jME, and no to the core jME code line.



Also, I think we should try to keep jME simpler and simpler every day, as opposite to add specif functionality that leads to more complexity.


After reading your reply I stopped for a moment and looked at the JME description in the main page.

Your totally right, I was think of JME as a Game Engine and not an Scene Graph engine.



To explain better my idea of channels (or layers) in a pseudo code:


Library.loadFromFile("Robot-high.jme", "robot-high");
Library.loadFromFile("Robot-low.jme", "robot-low");

Geometry robotMesh = Library.get("robot-high");
Geometry robotBound = new Box(1,5,1);
Geometry robotShadow = Library.get("robot-low");

Object.setRenderableMesh(robotMesh);
Object.setCollisionVolume(robotBound);
Object.setShadowVolume(robotShadow);



This ain't much different from the current implementation, just to separate what is supposed to be used by the Collision Manager, Scene Graph and the Lightning Processor...

To be honest I'm just throwing some ideas here, didn't go much deeper in it.