Hey I got my entire net code done for my game so looking into starting on the graphics part. So I'm either doing jmonkey or jcpt. Here are my questions:
Can you load in 3d date on the run with jME.
What is the easiest 3d editor to load and create data with for jME?
Does anyone have experience with both jcpt and jmonkey? How did one perform over the other? Which one has the easiest way of delving deep into the code and understanding it. Id rather work with something that has the easiest flexibilty instead of the easiest on the surface.
What would you choose between the two if you're worked with either/looked at the code? ANyway, going to sleep, going to evaulate both tomorrow.
I briefly googled jcpt and still could not find it… Anyways it had never cropped up in discussions on this board at all… Most of the comparisons of jME have been done against Xith3d. You might want to check out that project as well. anyways to address your questions:
Can you load in 3d data on the run with jME.
Yes
What is the easiest 3d editor to load and create data with for jME?
More important question is probably which format. I’d say md5 (link 1, link 2), ogrexml and this xml format, which I think is custom jMe one done for blender (dont quote me on that).
Does anyone have experience with both jcpt and jmonkey? How did one perform over the other?
No experience, but I am pretty sure that jME is the better one. This is a fan speaking… but also - otherwise jcpt would have popped up on these forums more.
Be sure to also check out Xith3d. And also our demos page. Oh… and we have the bestest community also 
Thanks for replying. Sorry about that. I actually meant: http://www.jpct.net/ NOT jcpt.
In anycase, I'm sure you haven't heard of it anyway. Yup, I've heard of Xith3D but the project seemed somewhat dead. In anycase, how would you compare Xith3d in terms of performance and scalability for a bigger project.
My main concern is not the quality of the graphics but the small size and performance. I saw the thread on the Quake 3 port and jMEs poor performance in comparison to Java3d and Xith, but that was back in 2005. How does it stack up now?
For some of the games I've seen on jME they were quite impressive (Cowboy game) but the download size was also huge.
I guess I am actually looking for guidance as to how to architect the game the best way. Take Runescape or Maid Marian (Sherwood Forest) for instance. Now Maid Marian is a shockwave game but I am guessing the concept is the same. How do they manage to retrain such small download sizes while still having a massive ammount of 3d data. How would one accomplish this with jME? And more importantly does jME have specific limitations in it's design that wold prevent this.
In anycase, anyone reading this, I'm really sorry for this. I know I should I just write some simple code for each engine and see what performs better and figure it out myself so ttyl, I'm going to do that. But post anyway what you think!
I just dont want to be sucked into the jME hype because from the looks of it the indie projects are pretty crappy (sorry hexxenn!).
Some work was done on JME by renanse and the quake port is now faster than the others.
The bang howdy ( cowboy game ) bundles up alot of the artwork and a jre for the installation. the art work is far more fattening than code, the jme core code is only a few mbytes. You could argue that World of Warcraft is too large at 2 gigs. If you need lots of art work, you could consider building a strategy to load and install the art on demand.
The runescape module has limitations, although smaller on the download size, the quality of graphics are very limited. Its your choice which is important between quality, quantity, speed and user interaction.
JME will run in an applet, this wold allow a quick start up time, whilst connected the applet could be downloading data in the background which will be required later.
You are wise not to get sucked into any hype whatsoever and with any project, always evaluate yourself. With respect to JME do however consider that most developers are not artists, hence some of the visuals may not look that great. JME is only a scene graph over lwjgl or jogl.
I don't think jme is designed to minimize download size. However you can of course trim it yourself to quite a degree if that is a priority.
What will dictate the quality of graphics in most games is the art assets not the engine.
They are also usually the major source of bloat (though if you are looking for a truely tiny browser game the engine will play a part).
If models and textures are nicely and consistently styled, specifically designed for the limitations of the game, and the game is designed to disguise their shortcomings, then low detail graphics can look good. Conversely a mishmash of models and textures designed by programmers tend to look bad regardless of the number of polygons or the quality of the engine. In short, quality in -> quality out.
Reuse is a major thing for reducing file size. If you want photorealism, right now you tend to want high poliy models with numerous high resolution textures specific to each object. If you want to keep your file size down, you will have for example, just one generic stone texture, one wood, one grass etc. Every stone object in the world has that same texture. This is quite plain to see (not always to that extreme) in many games. But if your game is slick and disguises things will, you can actually get away with it. Suspension of disbelief.
Also as mentioned, background downloading, compression, run-time generation rather than saving certain things. Minimizing the visible area and not using any level of detail, etc. It's all compromises in the end.
I supose what I'm getting at is, no engine will do it for you. If you have stringent requirements (eg. slick graphics, small download) then you will have your work cut out for you. Choosing your engine is hard, because simple test cases are not representative of real games. Also, the factors that restrain most none-commercial projects are not engine related. Visual quality is dictated by assets, performance is often limited by the way the game is implemented.
Mindgamer said:I've found this thread by looking at my referer log...and i thought i should leave a comment or two on jPCT. First of all: It has been mentioned in these forums a few times. Just use the search function and the correct spelling... :D
Anyways it had never cropped up in discussions on this board at all..
Second, jPCT was available long before jME surfaced. It was the first engine (that i know of) that jumped on the LWJGL wagon and the first one that adapted to the AWTGLRenderer when it was new. It has been used for various research, commercial and hobbyist projects (an incomplete list: http://www.jpct.net/projects.html).
However, it's fundamentally different compared to jME. It's a software/hardware hybrid engine, it's 1.1 compatible (the software renderer part), it's around 200KB in size (with all pros and cons) and while it's free for all kinds of usage, it's not open source.
It depends on your needs which one fits best. I've lost some users to jME that started with jPCT and i've gained some users that came from jME...so it's a draw... :)
Hey Egon, welcome to the forum. What we should really be talking about is convincing you to add software rendering to jME. 
Being open source is what got me into jme. Ok, well, having a game already fully programmed in java might have been an incentive, but I love being able to go into some jme objects and changing them to my likings. I just made a timestop effect for my game, and I had to modify a ton of things to get it to work. Couldn't have done it in any other engine.
wow shard how did you do the stimestop and what does it look like? I need to implements something like that also
http://www.youtube.com/watch?v=SsB1Y4TZwmM
I actually went into the ParticleManager, WaterEffectRenderPass, ProjectedGrid (and a few others) to make the changes I wanted. The hardest part was making everything resume where it stopped, instead of skipping around when I unpaused it. Particles still aren't perfect, but it looks good enough for me.
I'll post the changes I made sometime, when I can strip out the stuff that matters. It's all kind of jumbled right now.
You can achieve a pretty respectable timestop effect by just passing 0 to all your update methods instead of the real tpf. Just pass the real tpf to the one that updates player controls/camera.
Or you can pass, say, tpf/10 to create a time slow/slow motion effect.
Thanks you both… and the video looked impressive…
Alric said:
You can achieve a pretty respectable timestop effect by just passing 0 to all your update methods instead of the real tpf. Just pass the real tpf to the one that updates player controls/camera.
Or you can pass, say, tpf/10 to create a time slow/slow motion effect.
That makes the scene elements stop updating. I still wanted reflections on the water effect and lens flares in the sky. Also, the ugliest thing about not updating the projected grid (and you know this if you've run the jmetest) is that the water doesn't show up if you move the camera.
I actually haven't made it stop model animations, as I haven't implemented animations into my game yet.
Yep I suppose it would at that! I don't use either of those effects so had not considered it.
A quick statistic: JME and JME-Physics jars together are less than 18mb.
Trussell said:
A quick statistic: JME and JME-Physics jars together are less than 18mb.
Is that with or without the test package and all the resources? I bet you can cut the original size down significantly by creating your own jars that only include what you need.
That's without the tests-but you're right, in most cases you won't need all of the jars anyway.
Wow…the jme phsyics jars are pretty hefty. Looking at my target folder in my JME2 project, jme alone is only about 5.51 mb, not including the tests.