Foliage batched

After a rather complicated session of hacking the 3D core of jcrpg I can announce that with the previously batched terrain tiles, simple models, quad grass plus the new Foliage batching for the trees...the geometry batch optimization session is mostly complete! Tree foliage batching means a surplus of 20%+ FPS when animations are on and even more 30%+ when it is off. Overall a big boost of performance is working well now, and things mostly look like before, no loss of detail but a big gain of performance. Memory usage became a bit more varying, bigger garbage collections, but it seems to be okay, no signs of memory leak. Shots taken on a 6200Go, resolution is 640x400. (Walking in the forest it's around 80 FPS in that resolution. In 1024x768 it's around 45 FPS, without grass around 52FPS. Outside the forest it's around 70-80 FPS.)
P.S.: After posting this one I've found several weaknesses in memory usage of the new Batching. Fixed them along with the wrong cleanup of hmSolidColorSpatials field of J3DCore...now it's fixed in SVN, mem usage is correct...I hope! ;-D

Working on optimization

With help of one superb jme programmer I've added a new JME element to jcrpg which still needs some fine tuning. It's GeometryBatch, grouping the ground tile objects into one object of big batch. This boosts performance a bit, around 5-20% depending on several factors. I've got some problem with the lens flare and this new thing though which I've have to review for that reason.

P.S.: It is mostly done, the optimization and the lens flare now works correctly together. Check out SVN!

P.S.2: After the success of yesterday I managed to add batching to other parts as well. Simple wall tiles are now grouped together into batch, adding a performance bonus of 5%+. After that it occurred to me, that the best 3D part to add batching to is grass. So I rewrote VegetationSetup class to use GeometryBatch. It meant greater success, 2x/4x more grass (yet not animated and only single texture, no flowers yet) and good performance!

Optimization for the Caves

jcrpg received simple but huge optimization with lessening the view distance of outside objects when inside the cave, and the opposite also, when moving outside in the nature, the models inside the cave are rendered with a much lower view distance (all this is done in J3DCore.renderToViewport, each cube is checked for internalLight boolean property against the current player positions' inside or outside flag) . This boosts the performance much. It will be usable everywhere, where internal parts are covered with external parts, so it doesn't matter if they are not rendered. So exactly the Caves are most excellent for such optimizations, as the mountain covers it totally. Later internal parts of big buildings can be covered by outside walls, and using this technique FPS eater internals will be cut out from scene.

Meanwhile the cave code received much perfection and bug fixing, it is nearing completion in its first form. I've found a culling problem when externalRootNode's children are in very low number (when player is inside the cave), the whole internal scene was culled for no apparent reason. May be a JME bug, or what the heck! Anyway the solution is that when moving to internal parts from outside or back the order of internal root node and external root node are exchanged in its parent's child list (parent is the so called groundRootNode), and thus the problem goes away...maybe this is indicating a JMonkeyEngine bug or something I don't know about culling and node order?

I will think about some other geography improvements, maybe clean up things, adding comments to codes before moving on to wildlife. Before that you can expect a new prealpha release.

JMonkeyEngine upgraded and more caving

JME inside jcrpg has been upgraded to the new 1.0rc1 version. Seems to work well, and I like the idea of its new and easy texture and resource locator plus the java.util.logging system update in it. Also JME 1.0rc1 uses the new version 1.1.2 of lwjgl. Meanwhile I've been working on separating internal parts (like caves) from external parts (nature): internal and external parts now use different lightstates allowing internal cubes to be independent of outside lighting (Sun/Moon). You now carry your torch (point or spotlight) in the cave... later it will be optional, depending on your having a torch or other light source...so you will have a hard time without one such thing. :)

P.S.: In SVN version you can use bloom effect now on older cards without FBO support thanks to the cool JME update. Also I've found that the rootnode was put into a default passmanager without really needing that. I removed this step, and now performance with bloom and shadows are much better!
P.S.2: Another new feat: multilevel cave! Some fixes plus that in SVN, expect slow framerate with the multilevel dungeon...

Cave update

I've been working on the cave in the slow pace I can nowadays. I've made some new cave shots of the new quadratic cave walls and the nice cave entrance contributed by theotherhiveking. The cave will get some settable multilevel architecture and longer settable entrance gorge later. FPS is a bit low on the shots, but since then I've been trying to optimize it, mostly it is around 20-40 FPS on the 6200Go, with a nice VIEW_DISTANCE, so don't get shocked by the 20- FPS! ( Well, it's enough if I am the only one shocked by it! :-) )

The concept of Cube Overwrite

I've tried to reconsider geography, but finally arrived at the conclusion, that I shouldn't make big changes, it would make it more complex to have them more robust unnecessarily. I kept it simple: Cave is not a subpart of mountain anymore, Cave will be a geography just as any other, but new rules between overlapping geographies are added to make them usable inside/under mountains. Cubes can overwrite other Cubes, like the Cave entrance must overwrite the hillside Cube, otherwise you couldn't pass through the hillside. Check the SVN to enter the such generated Cave entrance into the dark undermountain cave! :-)

I plan to add further rules for Cubes that will give place for easy overlap design of Geographies. It will create fully playable, walkable geographies no matter if you want to make small geography parts that overlap big geographies. Just like small cave can overlap the mountain now without problem. I will have to clear up the code anyway during crystallizing the concept.

Also the forum life at freegamer seems to kick off well, people are reacting, asking and contributing generously. Please visit it, if you want to get your share.

Reconsidering Geography

While developing the new cave I've arrived at the conclusion that I must redesign the working of the Place/Geography system to carry on with the more complex multi altitude areas to make them available for later economic use for nations/cities/people. Caves must be made habitable by the AI, but that said the geographies must give access to more complex data about themselves, yet it must remain fast, flexible and easy to program. So I will spend some time now on thinking about the architecture of Places.