Poking around in the tests I found a reference to this class, is this something that would help a large number of light states (around 16)? There is no javadoc and looking at the class it looks very promising but would rather ask than dive in.
Also, I have a scene that will have about 40,000 to 50,000 vertices in a rather tight area. I think this is might be an issue. So far I have been using switch nodes and Dlod spheres, as well as shared texture states, single pass rendering. What about occlusion culling (which I don't think is implemented in jME), changing textures based on distance, organizing and rendering nodes based on light states, etc. Any suggestions would be really appreciated.
Right now I have been developing on a MacBook pro with an ATI x1600 (256 megs of VRam) which is rather high as far as target specs are concerned. With only 20,000 verts I am already starting to see FPS impact (80 fps). It could be texturing though, I may not be sharing textureStates as efficiently as possible, if I bump my quality up to high (large textures, more verts) I get an OutOfMemoryError: Direct buffer memory error.
I think you just need to be more agressive with your scene mangement and LOD. 40,000 verts should render fine with your specs, you could use a profiler to determine the bottleneck.
The LightControllerManager makes sure to apply only the most influential lights to a given primitive, you might want to check the test class to get more info about how to use it.
There is a (relatively small) memory in the JVM dedicated to direct buffers… you can bump it up by means of the flag:
http://www.jmonkeyengine.com/jmeforum/index.php?topic=5822.0
Sure, I know ALL about JVM flags and the heap size.
However, here is some more info on the memory error.
Background: Pool Game, multiple 'halls' each with its own theme. First hall, nine tables (other halls may have more), each table has 16 balls and a nice light above it.
All models are read and then cloned for each used copy.
Tables are switch nodes that go from 3,500 verts to 1,200 verts, table-lights are 200 verts no-switching. Balls are also cloned from a single DLOD node (vertices: low-12x12; med-24x24; high-36x36). TextureStates are also saved from each initial model construction and are reused for each cloned object.
Texture Numbers:
18 large textures applied to tables (better-filtering on closer texture)
9 Light 'colored-glass' textures
18 Psuedo-light textures
144 Ball Textures
| Dimensions | High | Med | Low |
| Table | 1024 | 512 | 256 |
| Ball | 512 | 256 | 128 |
| ColoredGlass | 512 | 256 | 128 |
| PsuedoLight | 256 | 128 | 64 |
| VM Memory | High | Med | Low |
| Single Table | 34MB | 15MB | 9MB |
| Nine Tables | 48MB | 21MB | 12MB |
(VM Results form NetBeans profiler)
Additionally, each table has it's own lightstate (for ball light reflection) and currently I am just creating lightStates and adding them to the Node.
I have tried using lower-quality textures on the table switch nodes, but there is a nasty lag while the texture switches. I am also toying with the idea of using switch nodes on the balls in order to remove the table light State. If anyone has any feedback on any of these approaches I am all ears.
Screenie
You're certainly using a lot of graphics resources for a simple game like this…
Have you tried setting the runtime flags to -Xmx1024m -Xms1024m ?
If it doesn't work with those flags on, then you probably have a completely different error.
I am SURE setting those flags would solve the memory error. But I would rather not…
You're certainly using a lot of graphics resources for a simple game like this..
I am open to suggestions, also please clarify: Too many textures, dimensions too large, memory use too high, etc..
I felt I was doing pretty good trying to keep my resource use as limited as possible, but I guess from your tone that is a no :(
This is TOTAL textured objects, not number of TextureStates created. Divide ALL numbers by 9 for number of texture states.
Texture Numbers:
18 large textures applied to tables (better-filtering on closer texture)
9 Light 'colored-glass' textures
18 Psuedo-light textures
144 Ball Textures
the default is only 64mb which is definitely not enough when u use good quality textures. at least bump up ur jvm heap size to 128mb
I take it from neakor's response that this is pretty common,
I would like to hear from other people as far as the resource usage goes. I don't think mine are THAT high, also others can use this information for comparision I think.
48MB JVM memory usage on High quality, (I dont get why the memory error though, it's less than 64MB)
I thought the VM heap had been bumped up to 128, but I guess I was wrong 
Also, any suggestions how to solve the momentary lag the first time switch nodes update their textures would be really appreciated.
Have you tried using compressed DDS textures? The GLU mipmap generator uses a lot of memory, and if you pregenerate the mipmaps you save that memory and also the overhead of runtime generation. For creating the DDS textures, I suggest you use ATI Compressonator.
I am open to suggestions, also please clarify: Too many textures, dimensions too large, memory use too high, etc..
The way I envision a pool game is where you have a single table and the gameplay orients around it. In your case you have 9 tables and multiple rooms, is this really necessary?
There is a (relatively small) memory in the JVM dedicated to direct buffers...
I never tested it myself, but if this is true then you would definetly have to change allocated direct buffer memory from the default..
Thanks for the suggestion, am going to check it out right now. 
The way I envision a pool game is where you have a single table and the gameplay orients around it.
My vision is not just a simple pool game ;)
basixs said:
My vision is not just a simple pool game ;)
Perhaps it should be for now? Focus on getting a really solid pool game out (AI, Physics etc) then all you have to worry about is expanding it into your nine table uber pool XD Instead of trying to get both done at the same time.
basixs said:
My vision is not just a simple pool game ;)
I smell the first MMOPH (Massively Multiplayer Online Pool Hall) coming... :-o
You'll battle NPCs like Minnesota Fats and ultimately work your way up to the PvP pool arena! :D
Am I right?!
Perhaps it should be for now?
Ummm, it is. However there ARE some things you DONT leave till the end.
ONLY one table is the REAL table. :P
Am I right?!
Close.....