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.

Contributions but no time for devel

On the forum many contributions, but the development is paused/slowed down for a short period because of lack of time. Cave development is under way, theotherhiveking jcrpg's new 3D artist ( I hope theotherhiveking won't mind that I call him that! :-) ) has created a very nice cave entrance and cave walls plus rocky ground, but till more time for development no news will be available on that.

P.S.: I could find some hours (hopefully I will find free time not too rarely in the next overloaded month) to start to develop cave geography in the mountains. I've got one preview screenshot for you.

Beware the wolfs!

We have got some new visitors in the world of Jcrpg...after the giant alien women left wolfs got around howling the house! :-) (Thank you theotherhiveking at freegamer forum!)

Contribution to the projects by new people around has become more frequent in the last few days! Yeah, wow, cool indeed! I am really impressed by people contributing their work for free! The quantity has really raised so by the hands of Charlie at freegamer forum jcrpg received an own subforum to better coordinate the development and contributions to the project. Thank you all for helping the cause! I've added the list of contributors (Hall of Fame) to the project tree in the SVN repository. The list will be included in all the future releases of jcrpg.

PS.: All the cool models are put to the repository of jcrpg for later use (I will put them in the svn when I have time, the bookcase by Harek, female/male and wolf models are already in). jcrpg will heavily need them when wildlife and human life will be more implemented. Until then I can only present demo screenshots... Wildlife will be the first part that gets implemented, after adding more geographies/waters and more climate perfection.

Testing higher polygon humans

Using this jcrpg freegamer topic's posted models I performance tested it on the low-end test videocard (6200Go), and I am amazed and surprised! I got usable performance and loading time! More then 10 of these models on the screen, lot more polygons, yet 20+ FPS! Check the screenshot (keep in mind that this won't be in the game in the near future, just a test screenshot)!

Patch it to go

Two days after the release I've received report of jerky movement in the snapshot. I couldn't stand without trying to repair it. Yeah, I could really find some new things to optimize. Now models out of camera are not added to the scenario, they are put there when turning. This is not JME's culling, but my calculation upon turning (in J3DCore.renderToViewport). The patch also contains the new smooth tree models. Download the patch at sf.net.

With this patch I could even get a very decent view distance of 35 cubes with load distance around 60 cubes (VIEW_DISTANCE=70, RENDER_DISTANCE=120) working on my 8800GTS, AMD64 X2 4800+ with a memory use around 500MB+ (although with a rather slow turning, big load time, but very usable moving forward/backward). For that of course I had to raise the heap size -Xmx parameter in the jcrpg.sh (or jcrpg.bat under Windows) to around 350MB (-Xmx350m). Anyway the optimal VIEW_DISTANCE is around 30-40 and RENDER_DISTANCE can be set to the double of these values. Take care of the -Xmx parameter in your jcrpg.sh/jcrpg.bat if you receive OutOfMemory or Heap is full. If you have less memory for testing set smaller VIEW_DISTANCE and RENDER_DISTANCE in the config.properties file.

Trees smoothed

DomoN has drawn my attention on the trees not smoothly shaded. Yes, they were not until now! :-) Exported to (non-rotated, exported normals) .obj instead of .3ds with normals set to smooth in blender. Looks much better...I had to spend some time figuring out that I've to modify the material files (.mtl) of the model and set Ka to 0.5 0.5 0.5 to have bright enough light on them.

Hooray for the bz2 - release

Yeah, another pre-alpha snapshot is out for you to test. Refactoring, optimizations, new partly billboarded models, new jungle design, other minor changes done. One week spent with finding bugs, testing and reorganize scenario building mechanism. Check out the results on sourceforge.net, and report back on performance, bugs, issues, experience, anything! While I was busy with the core of jcrpg, Harek our old visitor and Benoit Callebaut, a new one around jcrpg has contributed again some new things. Benoit has sent me an axe and a hammer and other useful things. He also put some models on freegamer jcrpg contribution topic. Thank you, people! Help is very much needed and appreciated now and later! :-) We all will meet once in the Hall Of Fame of jcrpg. (Which will be updated soon!)

Ruff in the jungle

After the optimization and bug hunting session, nearing release, jungle is getting complete. Check the screenshots!

jcrpg got into Linux Game Tome

Wow, at last after some weeks of waiting my submittal is accepted on happypenguin.org! :-) Thanks Linux Game Tome for doing so! The entry is planned to be updated regularly with the snapshot releases.

Profiler shows trouble

...trouble with freeing unused SharedNodes and it's siblings...should work, but it doesn't! RenderStates, SharedMeshes...all stuck... eating memory slowly. Will update on progress...

P.S. 1: It's JProbe trial that helped me to dump the heap and look at its content.

P.S. 2.: Seems to be a deeply rooted property of JME (probably down in LWJGL library which JME is using) I cannot yet change to my taste, so the problem is the TextureStates are not cleared even though they are not needed and theoretically shouldn't be referenced anymore. But solved the problem with caching the target foliage quads of the trees in a static HashMap, so only a few are created now and the game allocates fixed memory without eating it all when progressing in the game. So I consider it solved for now...release is getting close! :-)

Jungle preview, reporting to base

Days passing with many hours of optimization (scenario locking, cutting down unnecessary polygons, finding a brutal FPS eater fault - I've left pass manager running base pass unnecessarily when Shadows and Bloom were off, which resulted cutting half the FPS!) and profiling (to catch performance eaters) and reviewing jungle with billboard vegetation. Screenshot previews the jungle in its current under construction state. If jungle is complete, and optimizations are tested and ready to go a new pre-alpha release is good to be born! :-)

Pines billboarded

With room for making their LOD models more fine tuned, I think the pines are still worthy for two screenshots... ;-) Check'em! (In game they might look worse, but anyway they look great for me in action too, check SVN for the full experience...)

Room for optimizations, plans

Looking on the subject strongly, I've found some leftover bushes that were in need of new quad billboarding and ate some amount of FPS. I've done that. Meanwhile I've put JME's ClodMesh (computed level of detail mesh) into model loading, so some default level of LOD is available to any of the models in the game, if there is no way creating distance switched models (like the new trees are), we will use this new CLOD method instead (of course not for very lowpoly models). I will be working on the final steps for the 3D flora LOD model foliage, more optimization of FPS and 3D look this week, and then start to struggle on with climate (maybe quad based clouds on the sky), geography parts (cave and river/lake are main goals), and then hopefully at last wildlife. Yesterday I added colorization to the sunlight, reddish sunset, crisp midday. :)