I am just working on my own little gameproject and till I worked earlier with JME1 I just recognized that a lot have changed.
While testing around with JME3 there pop up a few questions I asked myself and this forum but didn’t get answers.
Lighting
I implemented muzzleflashs (simple particle emitter) in my game and use the CullHint methods to show and hide them.
Also I use a point light on each muzzleflash to get an lighting effect when firing a weapon.
As I use a point light for this i recognized that the lighting on high fire rates dramatically slow down the fps and
mulitply the vertices like hell. The point lights are build on each shot and will be deleted after a short time period from the firing control (rootNode.removeLight() etc.). Is there any way to tweak the performance on this?
As I implented AI and enemys I also recognized that while I let enemies spawn and deattach/delete them (enemy=null) the memory used in task manager is raising continously and is not really be effected by system.gc(). To create a game with low memory usage for use on android I just want to have an eye on the perfomance, since coding of the game begins.
In another thread there was the tip from normen to use DesktopAssetManager.ClearCache(), but I am using the SimpleApplication in my app where the AssetManager class is used and I didn’t have a ClearCache-method. Is there a way to use this class in SimpleApplication or another way to avoid this memory problem?
EDIT: Please move to forum category → Troubleshooting – General
You could go for deferred lighting, which isn’t done completely yet or just reduce the number of lights, e.g. just raise the light intensity instead of firing lots of lights.
You can cast the AssetManager to DesktopAssetManager but it should not be necessary to manually handle this, just make sure your java memory is not too large (sounds counterintuitive, I know) so that the direct buffers get cleared more often. If you don’t get an OutOfMemoryException then you technically haven’t reached the max.
Regarding 1): Is there any tutorial/information on deferred lighting in JME3 (which classes/methods are used)?
Regarding 2): I’ll try to play around with this.
Also I was just asking me, if there is a way to duplicate/mirror the terrain on one axe. Since I am using the Scene-Editor and Terrain-Editor to edit my Scenes/Levels I got the problem that I need a very long terrain which the cam can fly through in one direction. If I use the regular terrain-sizes (depending on memory usage) and strongly scale them i got very unsmooth terrain.
@d3ck3r said:
3) Ok, its not the answer I hoped for. Because its really annoying to place the objects if I use TerrainGrid.
Not really, when SDK integration is finished, you can place AssetLinkNodes that would load different objects on the map parts or just save the (probably grouped and optimized) meshes along with the terrain (the TerrainGrid can use a grid of j3o files).
Or depending on your case does not use terrain at all, maybee a set of pregenerated terrain tiles as a mesh is more efficient hardwarewise in this case.
viewrange (at least in picture) is quite low, so dynamic lod is not lowering the vertex count that much, it might be more usefull to just stack a bunch of meshes and only load the current and the next one, and deattach them them after leaving view.
You could create a own texturekey that is not cached at all, so once you leave the tile the alphamaps is unloaded as soon as possible.
@EmpirePhoenix said:
Or depending on your case does not use terrain at all, maybee a set of pregenerated terrain tiles as a mesh is more efficient hardwarewise in this case.
Rarely the case, for terrain like the terrain system does it its the most efficient way really.
I thougt also about adding terrain meshes but I just want to edit the whole Level on the scene editor (especially terrain) because i need a lot of levels for the finished game that I plan. I am just hoping now that the SDK soon will support larger terrain (TerrainGrid). If I understand normen right, then this is planned in future JME-releases?
I really like the engine but i got spare time to work on the game and just hoped that with JME3 it’s more comfortable to work with as with JME1 (esp. SDK) and on many cases my hopes become true. But while I worked with JME3 the mentioned problems are making me unsure about to use JME at this status and my main mentions are performance (+memory) and SDK-usability.
Don’t understand me wrong I love the work you guys did/do and I can imagine how much time that work costs and I also know that JME3 is still in beta-status. Just wanted to give a feedback from userperspective.
Look, jme is for programmers who could in theory do most of the engine code themselves. While the SDK gets you closer to a “game editor”, we will never supply something like the NeverwinterNights editor as it reduces the options for real game developers. So while we do plan to support TerrainGrid in the terrain editor you should see things that are not in the core engine as the stuff you have to implement yourself, thats the “game coding” part. The SDK tools are just there to help you in the process (prepare assets etc.), not to tell you how you bring all of that together.
Look, jme is for programmers who could in theory do most of the engine code themselves
I understand what you mean but why there exists classes in java and why there are standardfunctions? I suppose a good GameEngine does both. Support for experienced Programmers and easy Solutions. I guess it's just a free time question. I thougt that I could easily create a game with jme and still got the freedom to implement own code. The SDK is great but it's not fully finished (in my opinion) at the moment and that's what consuming time while I need to hardcode many stuff.
Just for example: If I look at other engines (commercial) I could easily change the terrain dimensions and start with my stuff.
@d3ck3r said:
I understand what you mean but why there exists classes in java and why there are standardfunctions?
To save programmers time. Same thing here, people come together to share code that would take too much time to write alone. Remember, for UDK for example, to get the ease of use (UnrealScript) and the flexibility of having the whole engine source you have to pay big bucks. Nobody stops you from implementing all this stuff if you think its so "normal" to have, SDK plugins as well as engine code for AI and whatnot. But you might find out its not really easy to implement it in a way that doesn't provoke trolls on the forum complaining about this or that not being right or how they want it. So, no point-and-click game making for jME3 on the horizon, theres just too many ways to do things and jME3 is simply not targeted at non-coders. And your example.. I told you three times now how its gonna be in the SDK and that you can do it in code no problem ^^
Switched to Unity. But I still got JME3 in mind and I really prefer it, just hoping for things to be added to SDK.
I totally understand the aspect of “code-freedom” but there are just things on which I doesn’t want to put too much time in. Just look at JME1 and what Renanse did for NCSoft: http://www.youtube.com/watch?v=g1MuK9W-v6I
point and click? Naaaaa!