So what do people want added to the Starter.pdf?

Assuming what’s in there is up to date, what else are people looking for inside the Starter.pdf file? Any astetic changes like formating, more pictures/diagrams or such? Lemme know what’s needed.

A conclusing, more complex demo (bringing it all togehter) would be nice.



For example an app where you can walk an animated creature around a terrain with skybox and interacting … showing off some of the latest cool effects … would be nice.



tending more in the direction of integrating all those cool features into a real game/app



But maybe this doesn’t belong into a starter ?



edit: cool work btw :slight_smile: - keep it up

I think creation of particle systems would be a great topic to cover.

Tips on performance maybe?

I’m hesitant about adding large, working programs to the guide. Putting it all together is limited by the programmer’s creativity. But a program can’t program what he/she simply doens’t know. I thought it would be best to keep it simple and explain a topic clearly and completly with limited source code. This way it’s easier to understand and the read isn’t so long.



Performance tips would make a good FAQ. Maybe that should be a different document in the wiki? No need for fancy design for that.



Particle system sounds like a good next go. Or maybe the GUI?

The particle system thing would be cool :slight_smile:

And the FAQ on performances tips should be very useful. I think it could be made as an article instead of a FAQ.


U could use the the character control demo as a guide as I said it was very simple and small, nothing complicated.

I agree ! Making a game often requiered to have animated characters, so it's good to know how to do it :) But I don't think the big tutorial on a "Putting it all together" is a good idear, as Cep21 said...

And the Gui could be nice too :)

Hello all,



perhaps advanced and complex collision detection using OBBTree ?



Adenthar.

this might be too simple but I just started using jME and the thing that has confused me the most so far is doing custom camera translations with the mouse.



FOr instance, how can I make the middle mouse scroll button make the camera zoom in and out. Stuff like that has been a pain to figure out for me.

That would be "How to use InputActions", which would be a good section as well.

Having just been through the guide and the jmetests to eval JME, and in addition to the points above, the following might be good:



. UML diagrams of subsystems eg: input system, to quickly understand how it works

. Primer on node and camera trans/rotations using quaternions and vector - this has come up a number of times in the forum in q’s on camera and node manipulation

. “Key points” highlighted eg: bounding types need to be same type for collision detection

. Possible to link the api javadoc to the jmetest and starter guide code for a complete integrated documentation set? So the doc would consist of: API doc, jmetests (with api hyperlinked code), and tutorial guide (with api hyperlinked code). I know of commercial tools that do this, not sure of any freeware ones, or if javadoc can include source?

http://www.developer.com/java/ent/article.php/629281

uml diagrams for some of the most used systems would be nice.

I agree with Cep21 about including working games but, i think some basic tutorials on a couple of game types would be nice. So they wouldn’t be included in Starter.pdf but they would be separate e.g. simpleFPS.pdf, simpleRTS.pdf or whatever then new users can look at starter.pdf first then look at the one relevant to the game type they are making. im writing a FPS game at the moment and if i ever get it working i dont mind writing the simpleFPS one, but at the moment ive had to put it on the back,back, backburner for various reasons.

Updating it to reflect the current API would be a good start - it’s slightly out of date here and there.



Personally, I feel documenting how to write games is a different topic to an introduction on how to use jME and its features. Both are worthwhile, but should probably be different documents.

Some explanation of the collision system provided by jME could be handy.



Also, perhaps more on the controller concept and some examples (it’s not so typical for scenegraph libraries).



Was the input system addressed in detail? Some best practices for handling keyboard and mouse input might be useful.



And a particle system section would be fun, as has been mentioned.





Thank you for your work on the guide, it was a very good quick start to jME!

The way Sun presented the Java3D API in these documents is very organized and effective. I used these docs to learn the J3API. You might get some ideas here.:



http://java.sun.com/developer/onlineTraining/java3d/



IMO, the one thing that kills potentially good OS projects is lack of coherent and concise docs…:?



I applaude your efforts to rectify this situation for the jME! :slight_smile:

How about camera control? It’s driving me freakin’ crazy. :wink:

Like winkman, I would also prefer a howto that puts all the stuff (graphics, sound, network, collision avoidance) together

for instance in a small, simple and extendable first person shooter.

This would also be a proof of concept.

"javac" wrote:
How about camera control? It's driving me freakin' crazy. ;)

That's pretty easy.
Alter the appropriate nodes translation/rotation.

If you have 1 root node and 5 nodes.

The 5 nodes are models and then you rotate the root node's x,y,z values.

Slightly OT - What’s really driving me absolutely crazy is the lack of an on-line API in the WIKI - javadoc is fine for the “devs” who write the code, but doesn’t allow “users” to embelish it and add comments.



A cross between the 3-pane browser sun used for their Java API merged together with Apache’s PHP API approach would be superb !

I realize that I can look at some of the test demos for jme, but it seems like somewhere in there should be an example of using a texture or two, I’m not recommending a full section for it, so much as including it in one of the existing ones (unless you wanted to cover multitexturing that is).