I like what you have in mind, but I also wanted a few more things:
1- Increase speed with occlusional culling
2- Simple physics, like what Galun said, but I'd like to add simple gravity(maybe roatational handling?)
-This would not take away from JME-Physics. Look at Irrlicht(the engine I used to use), they had simple physics, but people still had the need to get physics engines. Check it out yourself, http://irrlicht.sourceforge.net
3- Simpler way to integrate shadows, I don't understand how to do it, currently
4- I want the documentation to work better. I am all about support and documentation. I think we are good on support, but the ways to learn JME are… limited. People learn different ways, and I think we should give credit to them, like most engines don't. I want this engine to succeed, or I wouldn't really care since I know most of this stuff. If we can make it easier for them to get started, with everything they need here, on this one site, then it would be the simplest thing in the world. And I like simple.
5- Deformation. I want to be able to have a collision and deform the object that is hitting another, simply by supplying the point and radius of the deformation. So I have a collision, and at the point of contact, deform the mesh that is being hit at whatever radius I chose.
vear said:
theprism said:
A singleton with synchronized accesors and private instantiation
Making access to renderer synchronized (locked) is required, but i'm against all kind of private instantiation (and generally declaring stuff private). Java's "private" keyword prevents the subclass from redefining its parent, while protected allows access from the same package too, not just from the subclass. I think its the lesser evil to risk that a class in the same package uses a protected method, than to disallow subclassing. There isn't too many classes in the com.jme.Renderer package, and the classes are closely related, so the Renderer should be protected enough with protected instantiation.
Agreed. I already had to copy class sources of jme instead of extending them because the bloody private methods. :D
I'm pretty much a noob concerning advanced rendering and memory issues, but …
Concerning singletons :
They are handy, but there already are so many singletons that I ended up creating a singleton that gives me centralized access to the manifold of system singletons.
It really took me some time when learning jME to find out which singletons do what and which even exist.
They don't feature much in the tutorials either.
So beware of cluttering jME with even more Singletons.
Concerning Culling/Picking/Collision :
For ease of use event Listening really is the way to go. You can easily change what's going on under the hood or plug in different Culling/Picking Systems and the Listener doesn't have to change a single line of code.
there's a good reason Java already has so many listeners.
Even JmePhysics uses SyntheticButtons as listeners for collision events. ( Though i would rather like a different kind of listener for Physics decoupled from InputHandler, but that's offtopic )
Jedimace1 said:
2- Simple physics, like what Galun said, but I'd like to add simple gravity(maybe roatational handling?)
-This would not take away from JME-Physics. Look at Irrlicht(the engine I used to use), they had simple physics, but people still had the need to get physics engines. Check it out yourself, http://irrlicht.sourceforge.net
There was already a fairly complete solution that works well for me and aleast one other, that I know of, ironically its called simple Physics, hell, I ported it to jme2 and use it as my collision system along with a scaled down Strategy Cam for a little thirdperson shooter I'm putting together as a learning exercise.
the only thing it doesn't do is process collision geometry from nodes automatically, I came on here asked for some Advice and made a method for that
Hey, I'm really glad to see you guys making some progress on moving jME forward. I can feel some real energy here, but if I might make a few non-technical suggestions... (feel free to roll your eyes at me if you like :) )
1. Walk before you run. You should make designs for small feature improvements and then see them through. Get that going, see who participates and what they do best and make use of that.
2. Don't push away someone who wants to help. You need all the enthusiastic individuals you can get on a volunteer-based project such as this.
3. Keep the courteous, friendly nature together that jME's community is known for. I personally would count it as one of the project's biggest assets.
4. Have fun or don't work on it. You are here because you want to be, so you should be enjoying your time.
Ok, enough from the "ancient grizzly one" or whatever I'm now referenced as!
Good pointers renanse. Thanks for bringing those up.
renanse said:
ALL
Words of Wisdom well spoken
Also I think there is global appreciation and respect for Momoko's get up and go - And I mean Global
Sorry for the late reply…
1. Walk before you run. You should make designs for small feature improvements and then see them through. Get that going, see who participates and what they do best and make use of that.
That's a good idea if jME was still in early development, but right now jME2 is pretty much a stable and complete low-mid gen engine. Any improvements to jME now will be merely hacks to add new features. Instead major changes to the core are required in order for it to adapt more current paradigms of next-gen engine design.
2. Don't push away someone who wants to help. You need all the enthusiastic individuals you can get on a volunteer-based project such as this.
3. Keep the courteous, friendly nature together that jME's community is known for. I personally would count it as one of the project's biggest assets.
I am sorry if I sounded rude when I wrote those posts. By no way am I trying to push anybody away. I took me a while to write that post above so I guess I sort of lost the mood..
Either way, the original post was not meant to get some kind of community project going, I was simply looking for some comments/suggestions on a design I wrote for jME2.1.
What i got from your post, is that for jME 2.1 there is no need for my help. Which is good for me, because i can move on, and work on something else. I'm sure jME 2.1 will be useful for the community, a step for the engine becoming even better.
I didn't intent to reject your help or anything, what I wanted to say is that if your help consists of donating pieces of code from VL engine then I cannot accept it. The idea is to make a completely new design, based on requirements and next-gen ideals.
Momoko_Fan said:
Sorry for the late reply..
1. Walk before you run. You should make designs for small feature improvements and then see them through. Get that going, see who participates and what they do best and make use of that.
That's a good idea if jME was still in early development, but right now jME2 is pretty much a stable and complete low-mid gen engine. Any improvements to jME now will be merely hacks to add new features. Instead major changes to the core are required in order for it to adapt more current paradigms of next-gen engine design.
Fair enough, but my point was not that major changes are bad but that getting coding quickly is important to getting these volunteers/(interested persons) in and coming together as a group of developers. Anyway, evidently my unwanted two cents. *shrug*
Seems intresting I would help if I was more experienced but I only started with java 2 years ago and jme last year I'll probably make a contributions later on as if i did now they would be very noobish coding, however as of current i'm just editing code from other classes to fit my need, hardly anything innovative.
I'm slightly confused though don't we already have most the things listed or are you looking for ways to improve the classes or make better systems?
Bonechilla said:
Seems intresting I would help if I was more experienced but I only started with java 2 years ago and jme last year I'll probably make a contributions later on as if i did now they would be very noobish coding, however as of current i'm just editing code from other classes to fit my need, hardly anything innovative.
I'm slightly confused though don't we already have most the things listed or are you looking for ways to improve the classes or make better systems?
Well, JME not mentioned here http://www.gamasutra.com/php-bin/news_index.php?story=20848
Momoko_Fan said:
That's a good idea if jME was still in early development, but right now jME2 is pretty much a stable and complete low-mid gen engine. Any improvements to jME now will be merely hacks to add new features. Instead major changes to the core are required in order for it to adapt more current paradigms of next-gen engine design.
Eh... let's not forget that JME currently works pretty well for a lot of people. You make it sound as if the current version is incredibly outdated, which it isn't. Please keep in mind that the current group of JME users seems to be university classes, people making a game for fun, and the occasional small indie company. The whole monkey theming and cheerful community helps to build this image. You can remove the monkey image from the website, but that won't change the group of people that are using it. And let's be fair, no "enterprise" company is going to use a engine that is being developed by some guys in their spare time.
To be fair the changes proposed in the first post in this thread are all quite good, but I'm worried a bit because of the negative comments made on the current JME. Lots of people are happy to use JME at the moment, and if we go the usual open source direction of huge changes, bugs, and little documentation I fear there is more to lose than to gain by this strategy.
Mooving forward - how should we agree how something will be implemented ? - a poll or a discussion for each topic. There will of course be some over lap, so maybe ironing out the core elements in the first instance would be a good start - then we can pick what to work on.
I was thinking of having a thread for each "system" defined in the doc, like one for the geometry system, material system, etc. There we post a design for it, create an API interface based on the design, then assign people to implement the API in our jME21 repository…
What are the feelings about doing the multithreading first, seems that this is really messing with the guts of the system so may have some benefit in approaching this first.
Have already built a threaded worker system on the jme1.0 core using a queue system. Its not thread safe, but takes advantage of CPU juice. It will also allow for occlusion detection too without much overhead.
However there are two opinions withn the jme community, one being queue based, the other being thread safe. The thread safe option would have to be completed by an advanced programmer with knowledge of lwjgl and opengl pipeline. Guess we need to agree which one to go with …
theprism said:Has this been addressed now? Did a quick search and couldn't find anything that seemed to address this issue directly, but I don't really know what to look/search for besides "multithreading"...
What are the feelings about doing the multithreading first, seems that this is really messing with the guts of the system so may have some benefit in approaching this first.
Have already built a threaded worker system on the jme1.0 core using a queue system. Its not thread safe, but takes advantage of CPU juice. It will also allow for occlusion detection too without much overhead.
However there are two opinions withn the jme community, one being queue based, the other being thread safe. The thread safe option would have to be completed by an advanced programmer with knowledge of lwjgl and opengl pipeline. Guess we need to agree which one to go with ...