This is probably not bullet's fault...lpersona wrote: irrlicht + bullet + windows xp sp2 64bit = CRASH
Newton Dynamics is now Open Source!!!
-
Radikalizm
- Posts: 1215
- Joined: Tue Jan 09, 2007 7:03 pm
- Location: Leuven, Belgium
code (irrlicht+bullet) that works on my linux pc, doesn`t work on win xp 64bit. not only what i programmed myself, also this demo nomad posted http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=17910
-
jibblesmgee
- Posts: 42
- Joined: Thu Jan 06, 2011 9:12 am
I really like Newton. I see it more mature and stable than ODE, perhaps. The lack of cloth simulation or flexible objects isn't really a mater if you look for simple physics. If irrlicht had an interface with it would be most welcome too (like with many other physics engines, of course...) But seeing BitPlane's comments, makes me think this would be a good feature for the next Irrlicht.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
I only see bad stuff happening when integrating physics engine into Irrlicht.Mel wrote:If irrlicht had an interface with it would be most welcome too (like with many other physics engines, of course...) But seeing BitPlane's comments, makes me think this would be a good feature for the next Irrlicht.
Irrlicht would become even more harder to maintain, as I think theres already a huge TODO list on the graphics part. Besides irrlicht is supposed to be rendering engine not game engine. It gives us freedom to write your own wrappers/ layers for physics, sounds ect. and let irrlicht handle the graphics part.
Working on game: Marrbles (Currently stopped).
Actually when you want a physics wrapper that supports several physics libs use http://www.adrianboeing.com/pal/
We're programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by renovation:tinkering,improving,planting flower beds.
graphics engine + physics simulations = game engine? I don't think so.
Although they cover matters very diferent, and are conceptualy diferent, a graphics engine benefits a lot from physics simulations because they add another layer of realism to the graphics when they are in motion. It is not the same to draw things that look solid that are also "solid" on their own nature, a ball that bounces, that reacts to the displayed graphics, for instance, is more credible than a ball that passes through a solid wall. That is then why there is a collision response manager. But that manager isn't enough for complex applications. That is why we resort to physics simulators, write wrappers and so. Then, Irrlicht should have a proper interface for those simulators. Or provide a proper physics simulation to be a more complete graphics engine
Although they cover matters very diferent, and are conceptualy diferent, a graphics engine benefits a lot from physics simulations because they add another layer of realism to the graphics when they are in motion. It is not the same to draw things that look solid that are also "solid" on their own nature, a ball that bounces, that reacts to the displayed graphics, for instance, is more credible than a ball that passes through a solid wall. That is then why there is a collision response manager. But that manager isn't enough for complex applications. That is why we resort to physics simulators, write wrappers and so. Then, Irrlicht should have a proper interface for those simulators. Or provide a proper physics simulation to be a more complete graphics engine
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
It gives realism that is not really needed for a flexible, extendable, lightweight rendering engine. Everyone can make their own implementation on physics and is free to share it, tough not everyone needs and likes specific implementations of physics, thats why more complex physics stuff should stay out of irrlicht.Mel wrote:graphics engine + physics simulations = game engine? I don't think so.
Although they cover matters very diferent, and are conceptualy diferent, a graphics engine benefits a lot from physics simulations because they add another layer of realism to the graphics when they are in motion. It is not the same to draw things that look solid that are also "solid" on their own nature, a ball that bounces, that reacts to the displayed graphics, for instance, is more credible than a ball that passes through a solid wall. That is then why there is a collision response manager. But that manager isn't enough for complex applications. That is why we resort to physics simulators, write wrappers and so. Then, Irrlicht should have a proper interface for those simulators. Or provide a proper physics simulation to be a more complete graphics engine
And by rendering engine I understand that the main task for it is only to draw what you provide it.
Working on game: Marrbles (Currently stopped).
I think otherwise. Irrlicht, although it is the graphics engine, will inebitably find itself integrated with a physics simulator sooner or later in many cases. In the long run, it is more the benefit than the hardship, although i admit it is hard and costly to include something like a physics engine interface, the benefit is worth.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
-
Radikalizm
- Posts: 1215
- Joined: Tue Jan 09, 2007 7:03 pm
- Location: Leuven, Belgium
I think irrlicht should remain what it is now, a rendering engine, nothing more nothing less
Integrating a physics engine would cause bloat, and lots of unneeded code for people who just want to use irrlicht for non-gaming or non-simulation means, a global physics interface with a possibility of various engines would also pose restrictions on how many detailed aspects of a physics implementation you can use, not all physics engines are structured the same way so a perfect global interface without any (hacky) workarounds or loss of features would be close to impossible, and we're not even talking about the time it would take to fully implement it to a point where it would be perfectly stable
A tight integration with the rendering engine could also pose restrictions on what kind of games could be built with the engine, since not all games have the same physics requirements
For a lot of racing games/simulators a physics engine is run asynchronous to the game update at a higher update rate to maintain a detailed simulation and to be able to possibly predict high-speed collisions that might or might not happen the next game update, such a system would require a different implementation as opposed to a physics implementation for an RPG or an FPS for example
Irrlicht is structured to be very extendable, which you can use to your benefit for physics integration (although I don't see a lot of people actually using the facilities irrlicht provides, eg. the animator system), and in my experience implementing a physics engine has always been a very straightforward job
So I would say no against an integrated physics engine, I would however support a centralized community effort for such a global interface, we have many wrappers available for a lot of different physics engines (even multiple wrappers for 1 engine in some cases) so the talent and experience for building such an interface is definitely there
This would leave the choice with the programmer, but a stable and well-supported implementation would always be available if needed
Integrating a physics engine would cause bloat, and lots of unneeded code for people who just want to use irrlicht for non-gaming or non-simulation means, a global physics interface with a possibility of various engines would also pose restrictions on how many detailed aspects of a physics implementation you can use, not all physics engines are structured the same way so a perfect global interface without any (hacky) workarounds or loss of features would be close to impossible, and we're not even talking about the time it would take to fully implement it to a point where it would be perfectly stable
A tight integration with the rendering engine could also pose restrictions on what kind of games could be built with the engine, since not all games have the same physics requirements
For a lot of racing games/simulators a physics engine is run asynchronous to the game update at a higher update rate to maintain a detailed simulation and to be able to possibly predict high-speed collisions that might or might not happen the next game update, such a system would require a different implementation as opposed to a physics implementation for an RPG or an FPS for example
Irrlicht is structured to be very extendable, which you can use to your benefit for physics integration (although I don't see a lot of people actually using the facilities irrlicht provides, eg. the animator system), and in my experience implementing a physics engine has always been a very straightforward job
So I would say no against an integrated physics engine, I would however support a centralized community effort for such a global interface, we have many wrappers available for a lot of different physics engines (even multiple wrappers for 1 engine in some cases) so the talent and experience for building such an interface is definitely there
This would leave the choice with the programmer, but a stable and well-supported implementation would always be available if needed
Re:
well, for some reason.. the newest 2.78 version seems to be working now for me.jibblesmgee wrote:Could that be why I am having trouble? I'm using windows 7 (64 bit) and I finally got my linker stuff figured out and I made a rigid body and BOOM! [crash-no survivors].
naaaahhh... I think I just mucked up.