Sorry, my fault 
I mean the translation and rotation (especially the arrows and graphic stuff) of an object, after you selected the object.
I found already the LineCube, which will be build around the object.
I would like to try improving it^^
Thanks
ah ok…
that code can be found in com.sceneworker.util.jme package…
the classes are ScaleAxes, TranslationAxes and RotationAxes…
i know there are bugs with the transformation modifiers and i keep meaning to fix them but for the time being i want to complete a few more features before i go bug fixing…
so anything you see that might help please let me know…
thanks…
ok i've added more documentation to the google code page about how to get the scene worker tools palette etc up and running with SimpleGame…
hopefully this might help people out…
http://code.google.com/p/scenemonitor/wiki/AddingSceneWorkerToYourSource
it's in the second half of that document…
- Now that I am calling sceneWorkerHandler.render(), do I need to call SceneMonitor.getMonitor().updateViewer(tpf)?
- Can I hide the toolbar?
- I don't understand what the getTimePerFrame() method I need to define. I don't have a "tpf" variable in that context, and I can't guess what I should return (I am now passing latest tpf received on update).
- How do I cleanup everything, as oppossed to SceneWorker.inst().initialiseSceneWorkerAndMonitor()?
Aside from that, I am having some integration difficulties as I need to release camera and input control when SceneWorker is activated, but it's cool as I knew I had to deal with these two topics in my framework,
May I just mention that ISceneWorkerApp follows Microsoft's naming convention for C#. In Java, interfaces are not usually prefixed with 'I'.
Thanks for the great work. Your project is really useful.
jjmontes said:
- Now that I am calling sceneWorkerHandler.render(), do I need to call SceneMonitor.getMonitor().updateViewer(tpf)?
scene worker update updates scene monitor as well...
- Can I hide the toolbar?
not at the moment but i'll factor that into the next release...
- I don't understand what the getTimePerFrame() method I need to define. I don't have a "tpf" variable in that context, and I can't guess what I should return (I am now passing latest tpf received on update).
this is specifically for updates to TextureRenderers as if a texture renderer scene has controllers they need a time elapsed since last frame to update correctly...
i usually just pass the tpf parameter in base game....
i'm open to anyway of getting around this...
- How do I cleanup everything, as oppossed to SceneWorker.inst().initialiseSceneWorkerAndMonitor()?
i'm not too sure what you mean here...
could you give me an example?
thanks...
Aside from that, I am having some integration difficulties as I need to release camera and input control when SceneWorker is activated, but it's cool as I knew I had to deal with these two topics in my framework,
yeah this is an issue for me as well as i made a design decision that the input handler for the scene could be swapped with the scene workers input handler on a key press and vice versa...
maybe it would be better to flag that camera updates and input handler updates can be ignored in scene worker...
i apologise for this as i made alot of these decisions early on when scene worker was just being used by myself so obviously i've grafted many of my ideas of application structure into it's formulation...
any alternatives i'd be more than willing to discuss/implement....
May I just mention that ISceneWorkerApp follows Microsoft's naming convention for C#. In Java, interfaces are not usually prefixed with 'I'.
my naming convention is totally screwed up from working in 8 different naming conventions over the last 15 years....
the one i settled on is a bastardised hungarian notation from mfc with bits of mac carbon api conventions and a sprinkling of flex :)
it's been a while since i posted on scene worker so i'm posting now to let people know that scene worker isn't dead, just resting 
i will hopefully have a new version ready in the next few weeks…
i'm just bug fixing and refactoring locally at the moment but free time has been thin on the ground for the last few months…
new features
texture paint
export scene graph to source code
improved glsl editor using antlr grammar
all new camera controls and spatial modifiers
snippets and wizards
customisable keys
massive refactor of key design choices
a hell of a lot of video tutorials
so stay tuned
Ah nice! I was wondering what happened to this a while back. Good to see you're still working on it.
Edit: forgot to ask, do you have any jME3 plans?
Huscar said:
Edit: forgot to ask, do you have any jME3 plans?
Is there any plan of supporting other 3D engines? How difficult would it be to port SceneWorker and SceneMonitor to another engine that looks like JME?
I have downloaded the JARs but I get this:
java -jar sceneWorker.jar
Failed to load Main-Class manifest attribute from
sceneWorker.jar
Is there a simple Java Web Start link to launch this application?
there is a shell script and a batch file with the standalone package…
http://code.google.com/p/scenemonitor/downloads/list
that would have the neccessary launch command…
although this release is not very good 
theoretically it should be ok to refactor scene worker with other 3d engines as much of the presentation is populated at runtime based on object type…
the next point release will hopefully address this as i want to continue support jme 2 while beginning to support jme 3…
ncomp said:
there is a shell script and a batch file with the standalone package...
http://code.google.com/p/scenemonitor/downloads/list
that would have the neccessary launch command...
although this release is not very good :(
Ok it works now. I'm trying it. It reminds me a famous modeler, I don't remember its name...
ncomp said:
theoretically it should be ok to refactor scene worker with other 3d engines as much of the presentation is populated at runtime based on object type...
the next point release will hopefully address this as i want to continue support jme 2 while beginning to support jme 3....
Ok let me know when this aspect is addressed and I will try to support another engine that I use. I have some other questions :
- what is the relationship between SceneWorker and JME 3 GDE?
- have you implemented the trackball?
- does the SceneWorker already have a portalizer and a 2D to 3D editor (an editor able to convert 2D maps into 3D environments)?
Your project is more interesting than mine, my features are useless apart but useful in a bigger editor. I'm going to read your source code more carefully when I have some time. I'm looking for the most viable solution on the long term and I want to avoid useless fragmentation.
Edit.: I have just tried to resize and rotate a box. In my humble opinion, it would be easier to rotate the selected object with a real trackball and to resize it with some handles like in OpenInventor.
yes indeed about the trackball, the reason why it's not implemented was that i don't have a trackball mouse to test it with…
the next alpha will have the ability to customise the keys + mouse bindings for a number of interactions so users can hopefully set it to what they are used to/prefer…
sceneworker has no relationship to jme 3 gde, i haven't even started on jme 3 yet due to time constraints…
re : portaliser, scene worker lives on top of jme so if jme does not have it scene worker doesn't either…
re : 2d -> 3d, scene worker doesn't have this either but i'd like to see something like this in there…
at the moment i have 0 time but in the next few weeks i will put a better version together and release this…
in the meantime feel free to pm any questions or comments or bugs…
ncomp said:
yes indeed about the trackball, the reason why it's not implemented was that i don't have a trackball mouse to test it with...
the next alpha will have the ability to customise the keys + mouse bindings for a number of interactions so users can hopefully set it to what they are used to/prefer...
I spoke about trackball with a conventional mouse. You pick a "virtual" non visible point on an hidden sphere and while you drag, you have the object within the sphere moved. I implemented this thing once (it was a bit difficult but the result is fine for the final user).
ncomp said:
sceneworker has no relationship to jme 3 gde, i haven't even started on jme 3 yet due to time constraints...
I see what you mean.
ncomp said:
re : portaliser, scene worker lives on top of jme so if jme does not have it scene worker doesn't either....
Ok. My first incomplete implementation works with JME 2.
ncomp said:
re : 2d -> 3d, scene worker doesn't have this either but i'd like to see something like this in there....
Actually, it allows to quickly create simple huge levels that you can refine further with other tools.
ncomp said:
at the moment i have 0 time but in the next few weeks i will put a better version together and release this...
in the meantime feel free to pm any questions or comments or bugs....
Ok I have only one question now. Does your scene worker compute the collisions volume? For example, if I give a level with normals etc..., is it able to compute the optimal bounding boxes that wrap the walls?