Ooo!! I know this one! ;D Just modify the first post and change its subject.
It works! Thx!
Just checked & JPCT seems to handle texture-mapping correctly.
[quote]new feasibility test
[/quote]
60fps on my Linux laptop using the software openGL renderer (my gfx card is broken). Very very nice.
Erm, could you upload your source to the svn repository. Just whack it all in a directory called feasibility test 1 or something, no need to tidy. (or post the source in a zip somewhere here).
I’ll use it as a base for the physics development at the weekend.
Tom
Hmmm… It’s locked to 60fps max but I only get 35fps here - we may need to keep an eye on this, maybe lock to 20fps or something?
I’ve added an attempt at particles, not sure this is the best way to do it.
Source code here (and no scoffing at my coding!).
60fps for me, and rather cute it looks too!
Bit of tinkering with procedural textures (source here).
Looks quite nice, but JPCTs spherical mapping seems a bit odd…
maybe also try use the decimated version of the model (in the zip i sent), rendered with a color value of r=0.5 g=0.5 b=0.5
or even maybe use the current model, without a texture, just the static color, when its far from the camera.
A bit more tinkering: a couple of tracking cameras (& probably the worst starfield bodge ever perpetrated!)
it is starting to look like a space sim.
I find it odd that JPCT is rendering the space craft when it is obscured by the earth. (in wire frame mode)
It seems like a candidate for performance slow down when many objects on the screen.
I get some slightly odd behaviour - it’s like the JIT is taking a really long time to warm up. I start with around 5 fps, this slowly increases and after about 10s it reaches 20 fps. I hit 60 fps after about 15-20s.
The other weird thing is that hardware rendering ought to be working, so the JIT shouldn’t be having such a bit effect anyway. Regardless, once it’s all warmed up it looks right nice
I could be totally off here but since it doesn’t request any privileges it must be doing software rendering.
I noticed the wireframe thing too, what ‘bothers’ me more is the sharp edges though - they don’t ‘blend’ well. Perhaps this is easily solved, not really my cup-O-tea
Urgh, 'tis 2.07 a.m (was 9p.m.).
JOODE is almost intergrated with JBullet (though not svn uploaded yet). I havn’t managed to actually run any code yet becuase I have not finished the JPCT bindings yet.
If I feel like neglecting my PhD for another day I’ll do that tommorrow, but I have done my 4 hours (+) of commitment so it might have to wait till next weekend.
Tom
Right well I did a bit more today (Sunday). I’ve committed the work so far into JOODE’s SVN in a subdirectory called jbullet. Its a bit of a pain working with JBullet because it requires additional post compilation mucking about through ant, so development cant really be done 100% in my IDE. Anyway, I have no idea if anything work until I get the JPCT bindings working. Currently they don’t so probably nothing else works yet, so I don’t advise even looking at the source I have produced yet.
Tom
And i have been implementing a raytraced render… To begin with i started using my existing raytracing engine framework however since i had designed it in logical abstractions and heavily object oriented paradigm it unfortunately is not speedy enough.
So I will be creating a more procedural based engine which hopefully will be much faster. I should imagine that it will not be a mammoth task as i can re-use code and algorithms from my existing engine.
Moogie: Good luck! I reckon you’ll break new ground if you can get it fast enough!
Tom: How does JBullet bind to a renderer? I know JPCT pretty well so maybe I can help with that?
svn co https://joode.svn.sourceforge.net/svnroot/joode/trunk joode
you will find a subdirectory called jbullet. This has 4 sub directories containing source code.
-
jbullet-src contains the jbullet source as is (do not edit).
-
src contains the main JOODE adapter to jbullet. This probably doesn’t work becuase I can’t see the results yet.
-
JPCTbinding. Contains only three classes. JPCTBinding is a live binding to a JBullet geom. JPCTManager which listens to geom added events and creates (and destroys) bindings accordingly. And JPCTConverter which is the hardest part to write. This class creates a JPCT graphical representations of JBullet geometry classes. Currently I am only trying to create spheres for JBullet’s SphereShape, but it will be where all the action is eventually. The class structure is pretty much identical to the Xith binding. Writing converters are not hard, but can be time consuming and fiddly getting everyones concept of position lining up. We should get Spheres working, then off-center spheres and then probably jump straight to meshes.
-
Finally there is a test src directory which is where a TestingWorld resides, which will be a super class to all tests that involve JOODE-JBullet-JPCT functionality. TestingWorld currently makes the correct connections between JOODE’s dynamics and JBullet’s collision engine. It also instantiates a JPCT World. At the moment in the main I create a JOODE body and connect it to a Sphere, and add these to the dynamics and the collision world, which should cascade via GeomAdded events to the JPCTbinding. Once TestingWorld is rendering properly, then a specific subclass involving colliding Spheres should be created. (and then meshes etc.)
Currently the converter does indeed create the graphical object. But somewhere in the graphical setup nothing gets rendered. I have not instantiated any threads or anything. I ran out of development time last week and I am inexperienced with JPCT so no doubt I just havn’t set things up properly or set the renderer running. I am sure you could help. I was gonna copy how your demo works on Sunday, but if you think you can help that be great.
So getting the TestingWorld to render a sphere in the test src directory is the priority at the moment. All the event model etc. is probably garbage at the moment, but I can debug that pretty quickly once I can see :), it is working enough at the moment to add geoms. Oh yes, adding mouse movement and key board inputs would be great too. Look at the Xith TestingWorld to see the kind of functionality I am trying to reproduce. (PS dynamics is stepped via world.step(x), all geometry should be updated automatically but that might not work yet)
Tom
Oh yeah and…
JBullet uses this brilliant yet annoying method for object pooling requiring a post compilation instrumentation step. So run the testing world via the ant task in the build.xml in the root of the jbullet subdirectory: “run-JBulletTestingWorld”.
When I decide to integrate JBullet a bit deeper I will be getting rid of that. At the moment I don’t want to alter JBullet src.
Well I dunno if you ever got round to checking out my JBullet wrapper. I just noticed it was missing loads of libraries needed to run. Anyway the whole lot is in there now I hope.
The initial testing world now manages to move a sphere is response to gravity. I haven’t tested collision functionality yet (but this demonstrates JPCT and JBullet are in sync with JOODE). The jstackalloc dependency is driving me nuts so next week I shall get rid of that as my top priority. Thats quite alot of jbullet source code modifications though for no noticeable change in functionality, but it will increase future development productivity 10 fold.
It probably wasn’t 4 hours work, but I am a bit sick this weekend. I’ll try to be more productive next weekend.
Tom
I have looked at it but I’m not sure how you’re doing this!
JPCT really hates adding/removing objects; ideally all objects are pre-loaded prior to the first rendering, but your code seems to add/remove objects frequently?
My code will call jcpt.addObject() every time a new collision shape is added to the environment. I call the shape.build() once and clone shapes from cached primitives, but you are suggesting I should add them to the jcpt world upfront? How to I make sure they are not rendered until I want them to be? setVisible?
Anyway, my code adds objects as they are added to a CollisionWorld. So as long as you do that before starting your rendering thread then that will be done before any rendering occurs. It looks like spagetti at the moment because its event driven (and JBullet is adapted rather than modified), but once I get proper test cases you will see that the binding system JOODE uses means you don’t have to explicitly do any rendering code yourself, other than picking your binding and setting up the display. The JCPTManager ensures new objects have a rendered version, and destoryed collision objects removes the rendered version. Oh maybe you have just not got my code. New objects are not created every world step. Only the transforms are updated. Its a bit of a pain at the moment becuase Jbullet uses one set of Math classes, JOODE another and JPCT another so they all need to be converted between each other every world step. This is all done without garbage being produced, so apart from the exceedinly minor performance and memory hit its not a massive issue.
Maybe I should explain some concepts:
a JOODE dynamics World emits world step events every time step. It also emits Body added/destroyed events when a dynamics object is added or destroyed.
JOODE collision spaces ~= JBullet’s CollisionWorld (which is adapted to give the event model) emit geom added/destroyed events when a collision object is added or destroyed.
graphical bindings: currently Xith and JCPT called XithManager or JCPTManager are instantiated on a collision space and world. They listen for Geom added events or destroyed events to create live bindings to collision functionality. They listen to world step events to know when to update their local transformations on the current live bindings.
The JBuller adapter functionality looks a lot like a binding in many ways, because it too listens to world step events and updates the jbullets representation of position every time a body moves. A BodyInterface allows CollisionObjects (JBullet concepts) to be associated with dynamic bodies (JOODE). Its at the point of association that a listener is created to keep those associations in sync (note only one listener ever instantiated per world, that one listener updates all associations for that particular world per world step). JOODE will be converted to run off openMali sometime in the medium future, so eventually all this listening to step events will not be needed for the JOODE JBullet interactions. But I need to test JBullet before I can start integrating it deeper, so this superficial syncing is the best initial move.
Tom