IrrLichtRPG - Erring Light

[katoun]

For ODE,
I sugest you create a class Object that hold an ISceneNode an IMesh and
dBodyID(this is from ODE) like in the ODE tutorial from Irrlicht.
Hey, I'm glad you finaly choze ODE (as I sugested) because it is easyer to implement trust me on this( I know how hard is with Newton) and besides ODE is faster.
I have found some usefull tutorials( even though is is for Delphi, I now pascal too) one about simulating objrcts floating in water.
And I king of understood the buggy exemple that comes with the SDK and changed the car from a 3 wheel to a 4 wheel and it is a lost more stable on the ground
If you need some help with ODE I might try when I have some spare time ,OK?
And with that thing of reinitializing the device when changing config, whell I have tryed some things but It didn't worked.

[keless]

well, reinit'ing the device isnt critical, so dont stress over it. As for coupling scene node and IMesh-- I dont want to do that. In IRPG the server does the physics processing, so I need to keep IScene away from it. Instead, I want to couple IMesh->physics->Entity. The Entity information is what gets sent as world updates to clients, at which point the client updates their own Entity and its attached SceneNode (so, technically the physics is connected to the scene nodes, but indirectly becasue it has to go thru the networking layer). I'm spending more time evaluating it so that I can write a nice robust solution that will stand for a while (so that when I revisit it and make those speed enhancements, they're just code additions, not a re-write).

[Emil_halim]

how could you fade in and fade out your entire scene in your demo?

[keless]

gui fader, look at the code

[Guest]

I am glad you decided to go with ODE, and open source engine, but to be fair and to set the record straight, I do not think that your statement about the Newton engine is correct

As an actual update: I am in fact working on IRPG. I'm currently looking at the physics implementation. I've decided to go with ODE over Newton since it has Unix support and Newton currently does not. It also has better documentation, though it will be a little more work to implement. .

As of this week the Newton engine has been ported to Linux and it also works on Macs and windows
http://www.physicsengine.com/forum/viewtopic.php?t=1323

also theses comment here:

For ODE,
I sugest you create a class Object that hold an ISceneNode an IMesh and
dBodyID(this is from ODE) like in the ODE tutorial from Irrlicht.
Hey, I'm glad you finaly choze ODE (as I sugested) because it is easyer to implement trust me on this( I know how hard is with Newton) and besides ODE is faster. .

Do not know if this is correct either, ODE may be faster than Newton but that is just on paper, there has never been a concrete prove of that, just rumors, in ODE cannot sustain for example 10 box stack without auto sleep, so I do not know how this comparison is done when one engine can not solve the problem. Here is the work of some body doing that and see how only Newton and Novodex stack out and pass all the test.
http://www.ogre3d.org/phpBB2/viewtopic. ... 91&start=0

About Newton been difficult maybe this is a personal opinion it seen that for a group of people is just the opposite.
http://walaber.com/sp.htm
http://www.delphigl.de/eng_index.html
Just to mention two sample, an here are some of the more advanced implementations:

http://home.versateladsl.be/extremesoft ... 8-2005.avi
http://www.javin-Inc.com/TV65/VehiclePhysics.avi
http://walaber.com/stunt/sp_video2.avi
http://www.javin-inc.com/TV65/b0rked.avi
http://www.truevision3d.com/download.ph ... arloop.mpg
http://www.truevision3d.com/download.php?file=storm.avi
http://newton.delphigl.de/playground_planetarygears.wmv
http://walaber.com/stunt/sp6.avi
http://www.javin-inc.com/TV65/WeightOnShocks.avi

Those are just few videos from the Newton Showcase site, to prove the maybe Katoun is letting his personal dislike and lack of understanding of the engine to influence his judgment. Or perhaps he can substantiated these claims with some concrete prove.

Anyway I think that your decision to go with ODE is neither wrong nor right, you just picked the engine that better suit your need, but I just thought that a clarification was necessary.

[keless]

interesting that they have a unix build now-- and I didnt agree that ODE is easier. You have to do a lot more coding on the ODE side to get things the way you want. This is fine for me since eventually a proprietarily optimal solution should be neccesary (ie: I'm not doing vehicles right off, and I will need large-world optimization). However, it is nice to know that should I get fed up with ODE, I can turn back and start again with Newton after all.

[katoun]

Hello.
Any people that had learned C++ knows that static methods are limited because they can not call normal functions and I don't agree with making all methodes statatic.
As you may find or know Newton has defined the callback funtions static.ODE dosen't( besides in ODE you can see the source code a thing to apreciate) have the colision callback funtion defined as static witch gives you a lot more freedom when using it.
It is true that ODE haven't been developt for an year as I know(and is quit old)
so I agree that Newton is way mutch beter( I even love it) .But with a little(lot) of work ODE can become a very good physics engine.One thing is that it needs an better collision detection(witch to have swept cillision testing) and other thing....
I hope you are satisfied with my answer.
Good bye.

[katoun]

Ah....
Think about all those games that uses ODE (and are great games in fact) and optimised it to theyr needs....

[katoun]

Keless:
I have found something that might help you implementing physics,
check the link:
http://opal.sourceforge.net/
Good luck.

[keless]

excellent, Kat-- that looks very helpful! They even have a Volume Sensor (which is something I was going to have to write from scratch on top of ODE for the TriggerArea entities).

[Michele]

Keless,


I have perused your project, and it looks promising. I understand that you have planned for a GCC port of it, but have not yey had the time. I have spent a little time trying to get it to work with DevC++, but am having some difficulty with the STL code in the project. Any ideas on when you may take a look at moving it over to GCC as well? No pressure, just curious.

Thanks for what looks to be a very useful contribution to the Irrlicht community

[keless]

I've been pretty busy at work and with RL issues (moving, GF, etc), and havent been able to invest much time recently, though when I get time again, I'll start another fit of work (starting with the physics).

As for GCC-- what problems are you having? I know some of the path names are not all in the appropriate case (which will be a problem for Unix users), but as for STL, I used full namespace paths wherever possible; what could be the problem?

[schick]

Keless,

If you got Irrlicht working with OPAL. Could you post the source somewhere. Otherwise i will have a look at it during next week.

Cheers,

Schick

[keless]

I looked at the opal website when you pointed it out, but I still havent started writing the physics code (or done anything code-wise on this project since then). Right now client and server are both loading in a bsp mesh, its just a matter of hooking in the physics on the server side.

Tell you what I will do though: I'll take my current code and upload a 'most recent version' on the website for you guys to play with. You'll need to add OPAL to the project, but ODE is already in there and building with everything else.

[Guest]

i got 3 words, your game suck... Your writing way too much information than anyone wants to know about it...