I’m new to jME and therefore tried to start with a small example game where you shoot puppets with spheres. Unfortunately I did not come further than importing the models because I got so many errors when I was using the scene composer.
I couldn’t always edit the properties of the objects like local translation/rotation/scale or mass, gravtity or the position of a point light. I was able to get into the edit mode of the text field of the property, but however was unable to write anything, as if [jTextField].setEditable(false); was set.
I added to both the models (structure & puppet) a collision shape. When I put them together into a scene and let the physics simulation run, they fell through each other and a NullPointerException was thrown. After that I had to restart the IDE since the scene composer can’t recover from that.
I linked the puppet 12 times into a scene with the structure and added some transformations to it. After saving and reloading, all the transformations were reset but the origin of the puppets was somehow at the point I had moved them before saving.
Is there a newer version of the IDE than jME 3 RC2 where at least some of these bugs are solved? Are you getting the same errors?
Some properties cannot be edited, like world translation etc.
Why can't I edit for example world translation although I can move the object with the move-tools.
Surely not randomly but when you did something, what was it?
I wasn't able to see a pattern but I'll investiate in it.
Read up on how physics works, mesh vs mesh doesn’t collide
I didn't know this. When I tested it with cubes I made in Blender it worked, does is detect shapes like cubes/spheres etc.?
Thats the point, you can only save the link node in that scene, the rest is saved in the model file
The object I linked remained always the same. All I did was transforming the link node, which worked at first, but when I reloaded the scene it was all messed up.
To 1) I checked again and there are also values like collision group, damping, restitution etc. which can’t be edited, but only sometimes. When I first added a collision shape to an object, the values were not editable, but the second time they were.
To 2) I was able to reproduce the error two times by adding a point light to the scene.
@normen: Yeah, the ToolNode are messed up, also JMP Application action queueing mechanism: wrap every swing action via Runable are odd…
But don’t ask me for a better design or work around, I’m just not sastified with the old one but also don’t know my design of the new editor are better or not!
What I do it build up a so call JME Task Manager as a mediator between Netbean Task Manager and the Application. I rank actions into rank by its performance cost and predicted duration to finish! For example:
Changes in a Textfield (that’s the PropertyPanel or any of my custom Textfield) to modify a spatial postion of rotation are considered LightFast.
Changes like import big model, clone the whole spatial, change Mesh instance, generate physics are considerd HeavySlow…
And the Task Manager provide a custom warper (in form of Runable) for serveral LightFast at once. But notify Netbean system and declare a long task for HeavySlow and also watch for its result… etc
That’s a compact description, of course more sosphiticated algorimth should involve to sort this queue of actions but what I 've done it’s to care about action type more than the current system do. Then it’s safer and not crash, hang, stall just because of moving a Node. Because it predict the consequence…
Anyway, I know it going to be the time efforts have to be put into the SDK to improve it, consider this just a chat!
Issue 2 is fixed (at least the one implying the tool node)
@abctest123 said:
Why can't I edit for example world translation although I can move the object with the move-tools.
You can't edit world transforms in JME, only local. World transforms are computed on every frame considering the local transforms of the object and the previously computed world transform of it's parent.
When you move the object only local transforms are edited.
@atomix said:
also JMP Application action queueing mechanism: wrap every swing action via Runable are odd....
!
That's pretty classic, straight forward... and effective.
<cite>@nehon said:</cite>
That's pretty classic, straight forward... and effective.
“Every” is the keyword here. Of course it’s straight forward to do cross threaded action through a queue, classic too, as blocking style. What i’m telling that I try to involve non-blocking and predictive sort the action list with piority, cost, etc… And talking about effective in term of a software, please also consider the stability of that application. My old JMP crashed too much times when I open big model, and can not do anything meanwhile… That’s said, JMP currently do any action without concern predict the consequence is a “short” description of the problem. The Composer’s part is really a “first attempt code” compare to the quality of the overal and other modules. In fact, if we provide the good mechanism in place, we can also take much more advantages from external plugins than we currently do.
It also don’t have any mechanism to cancel the action in the middle or auto-save or something like that. Eh… I’m talking to much, sorry.
P/s : @nehon . Quick fixes are always appreciated!!
Not sure I get your point, but I agree the scene composer should be more stable.
Also its stability seems to differ depending on the os it runs on.
That said, reporting any crash/freezes like the OP did is the way to improve that stability
@atomix said:
My points: :p
- No offensive intended
- Composer should sort | merge the actions before commit to app.queue
- Should provide the way to handle | cancel heavy action, corporate with NetbeanAPI ( like LongTask ...)
As it is now theres no blocking at all in the SceneComposer between the threads anymore, all values are buffered and synchronized via a separate update process. For extending the SDK, all interfaces have methods that are called on the respective thread (awt/opengl). If you want you can stay in awt completely by using the already wrapped functionality (see wiki).
If you want to mix AWT and OpenGL you will have to do this one way or the other. As we don’t want to write a complete IDE and these are swing (or swt, which is the same) we have to mix AWT and OpenGL. Doing a scene editor isn’t that complicated if you adapt the data to the editor but the SDK does the opposite
Also I see big problems if you change the order of updates to the scene programmatically without knowing the task content (e.g. from a plugin) and frankly I don’t see much reason for it either, the process won’t get much faster. Maybe I am misundstanding something?
Edit: generally I think its quite straight forward: the logic happens on the awt thread and the commands are enqueued to the gl thread. Thats why its important that the order is kept. If the app enqueues first e.g. the attaching of a spatial and then a movement these will be executed sequentially on the gl thread, in the same order. If theres things that have to be evaluated in the l thread, the logic code is enqueued to the awt thread. Pretty standard asynchronous threading model really. Ofc tjis can get hairy with mouse input but the current interfaces for mouse handlers already have the threading sorted out and I intend to change the mouse input behavior for plugins as well (see that thread where somebody offered to improve the scene composer, I explain most things there).
I meant “sort” but not change the order, which I should call “rank” the action type, based on its predicted duration and performance cost (This is how my Task differ from current orginal Runable) ! then I submit bunch of related actions at once.
For example: I want to move ten spatial the same amount, (i know the current composer can not, but it can in my modified version), the ten translations are send into the queue in a same Runable.
Another example is model loading, if I have a big model which can take time to load in place, i declare a Long Task with Netbean Platform and still able to do things, in other TopComponent, or even in the Composer with just the parent Node of the current loaded spatial Lock down. If it load into rootNode, of course the whole scene should be locked down, but still not neccessary. I want to let the user have more room to compose what ever their want in the mean time.
This is what I call a hidden trap, Callable become AppTask, but doesn’t handle the user any reference to the Task to cancel it… That’s why I add a method to give the AppTask of specific Callable if need…
<java>
public <V> Future<V> enqueue(Callable<V> callable) {
AppTask<V> task = new AppTask<V>(callable);
taskQueue.add(task);
return task;
}
//
public void update(){
AppTask<?> task = taskQueue.poll();
toploop: do {
if (task == null) break;
while (task.isCancelled()) {
task = taskQueue.poll();
if (task == null) break toploop;
}
task.invoke();
} while (((task = taskQueue.poll()) != null));
</java>
Anyway, this is quite out of topic, can you point me the right SDK improvement topic?
If you enqueue the tasks they will be worked off in the next frame, all of them. With inlined code from the compiler thats virtually the same as if you had them all in one method and execute that. I still don’t see the point in somehow “ranking” them really? For being able to cancel the tasks, you can always add a progress indicator to your process, that whole API is thread safe and you can use it from any thread.
