I have finally created a new build of Odejava.
So that builds can happen more regularly (i.e. whenever there are major changes), I added an “cbuild” target to the odejava-xith3d’s build.xml.
Download here: https://odejava.dev.java.net/servlets/ProjectDocumentList?folderID=2192&expandFolder=2192&folderID=0
Users of the really really old build will have to change instances of “new Space” to one of the space types like “HashSpace”.
Cheers,
Will.
Any changes / fixes ?
Everything that’s been added to Odejava over the last 12+ months. I can’t recall off the top of my head but the log messages in the mailing list: https://odejava.dev.java.net/servlets/SummarizeList?listName=cvs should tell the story.
Most Odejava developers have been building from CVS as far as I know, this is mainly for new users.
One notible recent change is the addition of a dependancy on the Apache Commons Loggin API (.jar included) and the removal of the dependancy on Log4j - please adjust your classpath accordingly.
Will.
Is Odejava still being worked on / are there plans to invest some more time into it? I’m prepared to accept that making the Trimesh dynamics work correctly is too large of a task, but there are two features which I would like to see being implemented: contact depth, body auto-disable
Since manual body-disable as well as auto-body-enable work as is, one can implement an auto-disable capability directly in java, but I imagine the motion test can be done much faster natively.
If I understand it correctly, contact depth would decrease the amount of “trembling” considerably, making the eventually implemented auto-disable test perform more precisely.
I would also like to ask, why the step() function causes an EXCEPTION_STACK_OVERFLOW and native crashes so easily (small simulation with 5 GeomBoxes)? Is there a workaround or is it deprecated completely. stepFast() is working well for me.
To avoid stack overflow, you must start your program with the vm arguments -Xss10m (10 mb less or bigger) to make the stacksize bigger.
IIRC the native stack isn’t big enough, which is not adjustable by setting VM parameters. It has to be set in the native lib.
Thanks, that solved the issue.
[QUOTE]IIRC the native stack isn’t big enough, which is not adjustable by setting VM parameters. It has to be set in the native lib.
[/quote]
That’s what I thought also, that the .dll needs to be recompiled (always expecting the worst).
First post here
I had the same problem with the stack overflow and tried the -Xss command at the command prompt and using Runtime.exec() but they did not seem to work.
However, when I reduced the stepInteractions() to 5 this seemed to have solved the VM crash problem.
Slightly off-topic by is there a way to specify a non standard option like the mentioned -Xss in the manifest inside of a jar file?
The -Xss option works only on for threads spawned by the vm itself. The main thread gets the default stack size for the executable. Thus put your code into a new Thread.
Not as far as I know. But at least you can specify it for a Webstart app (jnlp).