Page 1 of 1
Posted: Fri Jun 17, 2005 8:07 am
by Steve F
¡Yo también! (it means 'I also')
I am looking closely at naming and storage structures.
I have a copy of ODE physics and collision library. It's not perfect, (well, I mean mature), but it looks like a good starting place. It takes pointers to the world mesh to know where static surfaces are. Dynamic objects are only modeled in terms of mass, position, accl, and collision bounding box. It is up to the implementor to step the physics engine, retrieve the position and orientation of each dynamic object, and then call display routines (as far as I have been able to tell from study; I am going to finish some other obligations before playing with ODE). I don't know yet if I will have to perform culling outside of ODE or if it is efficient to localize the static mesh to the dynamic objects in real time. If the thread library in libito works well, I have an idea that culling and LOD can be performed on a low priority thread not bound to the frame rate.
In any case, I am looking forward to figuring out an implementation of a basic 3d game engine. These draw routines are a real time saver; Thanks ooPo!
Posted: Fri Jun 17, 2005 2:02 pm
by rinco
Yo Steve,
Maybe we can work together on this one. I've got ODE running on my
PS2... it ports very easily.
I also tweaked the ODE Drawstuff lib so that it can use DreamGL. I would
have checked it into CVS months ago, but it locks up if I don't pass
-notex (ie: no texturing).
I wish to make it go faster, but I've yet to decide how.
Posted: Fri Jun 17, 2005 10:16 pm
by Steve F
Cool, count me in.
I learned of another group that ported ODE to ps2. One of the problems they had was that even though they flagged for type float, there remained some references to doubles that caused problems. One place to check is dRand. Converting to float and a more efficient rand algorythm will speed up the step calculation.
Before I found ODE I was planning on culling my large static trimesh in a low priority background thread. The generated list of triangles would be only those triangles near any dynamic objects and dynamic objects near each other. Near would be calculated as constant + factor * velocity. I haven't tested anything but I figured parsing the large static trimesh over many frames (up to 10 frames or so) would reduce per frame CPU load. That should make per frame collision detection of the dynamic list fit within a frame along with the physics calculations and GIF dma's. I'm curious how well ODE will tolerate having a trimesh geometry object altered or swapped on a per frame basis.
I noticed that the PS3 will use OpenGL ES. Although libito seems to be the best graphics library offering, I am starting to lean to OpenGL style so I can drift over to ps3 next year.
Anyway, I would love to see ODE is CVS. I'd be glad to contribute implementation notes and bug fixes.
Posted: Sat Jun 18, 2005 4:55 am
by Drakonite
Split from completely unrelated post by request.
Posted: Sat Jun 18, 2005 7:28 am
by urchin
Over the past week I've been playing around with ODE and openGL on my laptop in an attempt to improve my grasp of 3D physics.
I'd be very interested to help with something PS2 based.
Posted: Sat Jun 18, 2005 3:45 pm
by rinco
I imported my ode-0.5 port into ps2sdk-ports/ode.
Ode itself doesn't require dreamgl, but drawstuff and most of the ode
test samples do. I'm having a few difficulties with cvs and dreamgl
right now... and ode assumes dreamgl is installed in $PS2DEV/dreamgl.
So you may have to copy the dreamgl .h and .a files manually.
When running the test samples be sure to specify -notex... ie:
ps2client execee host:test_collision.elf -notex
I use dSINGLE for floats (include/ode/config.h). I found dDOUBLE was
slower. I also found using less collision points was faster.
I copied libVu0.c/h into ode/src... but I have yet to make any vu0 optimisations.
I did not plan on doing any more ODE for a few weeks. But that shouldn't
hold you back from doing awesome.
Posted: Sat Jun 18, 2005 3:59 pm
by Guest
rinco wrote:I use dSINGLE for floats (include/ode/config.h). I found dDOUBLE was
slower.
Which makes perfect sense since there is no hardware double-floats...
As a general rule, all use of doubles should be avoided, including the act of the compiler silently promoting floats to doubles internally.
Posted: Sun Jun 19, 2005 12:15 pm
by Steve F
I'm having the weirdest problem getting the ode test programs to build. I have a fresh dreamgl and it builds okay. ode builds okay also, including drawstuff. When I cd to $(PS2DEV)/ps2sdk-ports/ode/ode/test and run make I get a lot of 'undefined reference to' involving drawstuff. Here is the first 10% or so of make output:
Code: Select all
ee-g++ -D_EE -O1 -G0 -Wall -I/usr/local/ps2dev/ps2sdk/ee/include -I/usr/local/p
s2dev/ps2sdk/common/include -I/usr/local/ps2dev/ps2sdk/ports/include -I. -I../in
clude -c test_ode.cpp -o test_ode.o
ee-gcc -mno-crt0 -T/usr/local/ps2dev/ps2sdk/ee/startup/linkfile -L/usr/local/ps2
dev/ps2sdk/ee/lib -L/usr/local/ps2dev/ps2sdk/ports/lib -L/usr/local/ps2dev/dream
gl/lib \
-o test_ode.elf /usr/local/ps2dev/ps2sdk/ee/startup/crt0.o test_ode.o -
lode -ldrawstuff -lm -ldreamgl -lpad -lmc -lmf -lstdc++ -lg -lc -lkernel
ee-strip test_ode.elf
ee-g++ -D_EE -O1 -G0 -Wall -I/usr/local/ps2dev/ps2sdk/ee/include -I/usr/local/p
s2dev/ps2sdk/common/include -I/usr/local/ps2dev/ps2sdk/ports/include -I. -I../in
clude -c test_buggy.cpp -o test_buggy.o
ee-gcc -mno-crt0 -T/usr/local/ps2dev/ps2sdk/ee/startup/linkfile -L/usr/local/ps2
dev/ps2sdk/ee/lib -L/usr/local/ps2dev/ps2sdk/ports/lib -L/usr/local/ps2dev/dream
gl/lib \
-o test_buggy.elf /usr/local/ps2dev/ps2sdk/ee/startup/crt0.o test_buggy
.o -lode -ldrawstuff -lm -ldreamgl -lpad -lmc -lmf -lstdc++ -lg -lc -lkernel
/usr/local/ps2dev/ps2sdk/ports/lib/libdrawstuff.a(drawstuff.o)(.text+0x678): In
function `Texture::Texture[not-in-charge](char*)':
drawstuff.cpp: undefined reference to `glGenTextures(int, unsigned*)'
/usr/local/ps2dev/ps2sdk/ports/lib/libdrawstuff.a(drawstuff.o)(.text+0x684):draw
stuff.cpp: undefined reference to `glBindTexture(unsigned, unsigned)'
/usr/local/ps2dev/ps2sdk/ports/lib/libdrawstuff.a(drawstuff.o)(.text+0x6b4):draw
stuff.cpp: undefined reference to `glTexImage2D(unsigned, int, int, int, int, in
t, unsigned, unsigned, void const*)'
/usr/local/ps2dev/ps2sdk/ports/lib/libdrawstuff.a(drawstuff.o)(.text+0x6cc):draw
stuff.cpp: undefined reference to `glTexEnvf(unsigned, unsigned, float)'
/usr/local/ps2dev/ps2sdk/ports/lib/libdrawstuff.a(drawstuff.o)(.text+0x748): In
function `Texture::Texture[in-charge](char*)':
drawstuff.cpp: undefined reference to `glGenTextures(int, unsigned*)'
I updated my cygwin, ps2sdk and the relevant modules, dreamgl, ps2Perf, and ps2sdk-ports/ode and still I can't get a good build. I tried messing around with the order of libs in the Makefile and insured it can see all the include and library files. I didn't move the dreamgl.h and .a files because my dreamgl is already in $(PS2DEV)/dreamgl .
Posted: Sun Jun 19, 2005 12:22 pm
by rinco
My bad, I forgot to check in my headers with extern C declarations.
Dreamgl in CVS updated.
Posted: Sun Jun 19, 2005 12:51 pm
by Steve F
It built with no errors! Thanks rinco.
Posted: Mon Jun 20, 2005 11:16 am
by Steve F
gorim wrote:rinco wrote:I use dSINGLE for floats (include/ode/config.h). I found dDOUBLE was
slower.
Which makes perfect sense since there is no hardware double-floats...
As a general rule, all use of doubles should be avoided, including the act of the compiler silently promoting floats to doubles internally.
I added the compile option -fallow-single-precision to the makefiles of dreamgl, ode, and the ode test programs. It definitly shows a speed increase. Are there other options to prohibit silent use of doubles? And if I want to be certain, would I have to compile with -S and then look in the assembly for ... what? A call to a float to double routine and back again? Or look for 8 bytes being reserved on the stack for arguments of double when I have all my variables declared as float? That kind of thing?
Posted: Mon Jun 20, 2005 11:48 am
by rinco
This is good. And I'm sure your plan for finding doubles will work.
Perhaps before you go looking for doubles, maybe you could help me by
figuring out why collision_trimesh.o does not compile?
Posted: Mon Jun 20, 2005 1:49 pm
by Steve F
I got as far as finding in collision_trimesh.cpp:
dxTriMeshData::dxTriMeshData(){
#ifndef dTRIMESH_ENABLED
dUASSERT(g, "dTRIMESH_ENABLED is not defined. Trimesh geoms will not work");
#endif
}
fails because the argument 'g' is undeclared. The error message handler 'dUASSERT' usually takes an object ID as the first argument. In this case there is no object at this point in the declaration. I replaced it with:
dUASSERT(0, "dTRIMESH_ENABLED is not defined. Trimesh geoms will not work");
and collision_trimesh.cpp compiled and linked into libode.a . There should really be an ASSERT that takes just a text string as it's only argument or maybe it's overriden but I didn't try that. I looked for the definition of dUASSERT but didn't find it right away so I stopped looking for now.
But, all trimesh functions need the OPCODE library. I'm not able to look at building OPCODE tonight and it doesn't look obvious to me how to properly build it. I'll look at the original make files and try to figure out how get it set up and then try the other test programs.
Posted: Mon Jun 20, 2005 10:01 pm
by rinco
I thought it was strange code, but moving on...
I've compiled libopcode and libice as stand alone libs, and included
the trimesh stuff with libode. But I'm not getting any trimesh collisions
yet.
cvs updated.
Posted: Mon Jun 20, 2005 10:31 pm
by Steve F
I didn't get it to work either. Seems to compile okay. Loading with ps2client just stays on ps2link screen.
My cygwin env didn't like the makefiles. The <<<<<<<<< and ========= caused make to report invalid seperator and gcc syntax error. I don't recognize these features. What would I search for to read up on these?
Posted: Mon Jun 20, 2005 10:33 pm
by rinco
<<< === >>> is how cvs merges differences when it can't figure out
how to merge.
Posted: Wed Jul 27, 2005 7:31 am
by urchin
I just tried your port, and I can get the examples to run, but I only get primitive collisions, not trimesh ones...
interesting, as I statically hacked ODE and OPCODE together into a demo earlier today and it was kind of working, but now I get an exception when the two meshes collide...
one mesh is a static square and the other a cube falling under gravity... when the two collide, the cube's coordinates freak out to minus several bazillion in each direction... when I run it on my PC, the cube hits the surface, but slowly sinks in...
I'm a bit stumped as to what to do next, there seem to be no free alternatives...
Posted: Wed Jul 27, 2005 11:51 am
by Steve F
Try compiling OPCODE with -O1 or with -O2 but add -fno-strict-aliasing .
Posted: Wed Jul 27, 2005 6:35 pm
by urchin
Cheers, will try that...
You having much luck with it overall?... Is the performance any good?...
Posted: Wed Jul 27, 2005 9:29 pm
by Steve F
Well, everybody seems to have problems with trimesh collisions. There isn't consistent maintenance of patches on ODE cvs. The unstable branch should have most of the well known fixes. It seems that the games that currently use ODE also have lead engine programmers that start with ODE, fix the problems, but never propagate changes back into cvs. The latest Myst game due to be released soon uses ODE. Their lead programmer commented on their development experience last month.
I backed off ps2 dev&test while I look at other game engines (and sadly, the PC as the game platform). All have basic physics and some have provision for using ODE as the main physics engine. I've found that ODE is very well represented in the community and well thought of dispite its problems with bugs.
The other thing I'm looking at is the OpenGL requirments. DreamGL seems to fail when textures are used. I started looking at porting ps2gl hoping for a more complete (and working) OpenGL implementation. I also have my eye on ps3 as a platform for my game and early specs indicate it will support OpenGL ES so I have been studying that too.
So, a solid OpenGL on ps2 would open the door to engines like Torque, Crystal Space 3D, OGRE, or OpenSceneGraph. I'm setting up a PC so I can test the engines and learn to what extent they meet my game's physics needs before I spend more time on ODE.
I'm too new to all this to be an expert evaluator so I'm still learning what I need to learn about so I can learn that too (if you know what I mean). I just read that Sony will sublicense Unreal 3 engine with the PS3 SDK. I may spend some more time looking at Epic's earlier engines that have been released as free.
Posted: Wed Jul 27, 2005 10:16 pm
by urchin
I'm still only experimenting with cube shaped tri-meshes on the PC right now, but this patch makes a hell of a difference...
http://q12.org/pipermail/ode/2005-July/016352.html
Posted: Wed Feb 08, 2006 11:05 pm
by todi1856
Hi everyone , i just started using ODE on PS2.
I succeded in launching the program on PS2, but in a while it always crashes.
While compiling ode i have encountered few errors
1) Strange but my compiler didnt have alloca.h , so i replaced it with malloc.h , alloc with malloc
2) The second problem was with opcode
In File OPC_IceHook.h
i had error , array with negative value
#define ICE_COMPILE_TIME_ASSERT(exp) extern char ICE_Dummy[ (exp) ? 1 : -1 ]
so i replaced with
#define ICE_COMPILE_TIME_ASSERT(exp) extern char ICE_Dummy[1]
Maybe someone encountered familiar errors , and could tell me , if this is the source of my crashes :(
Posted: Wed May 14, 2008 12:02 am
by helloween
Hi,
I had the same problem, if I understood well:
in the file IceTypes.h , there is a compile time assert test that gives this error if the size of the bool is not equal to 1 line 71
ICE_COMPILE_TIME_ASSERT(sizeof(bool)==1);
and the size of a bool on a ps2 linux is 4.
I don't really understand why they do this test with bool==1 but just by commenting this line or changing the size it compiles fine.