Design Changes

[Andy Price]

This will probably get me 'flamed' but I felt I had to mention it and please note I've posted this in the "Requests and Feedback", emphasis on 'Feedback'.

The way newton uses callbacks seems to be a limiting factor in my game in that, it forces me to have a lot of static member functions. The alternative is to use global functions or store pointers to other objects in the 'UserData' of a Newton object. I can see that this is a good idea for the material callbacks - such as two objects colliding and I've written functions to deal with that but.. is it really necessary to have the 'ForceAndTorqueCallback' ?

I'm sure quite a few people won't even see this as a problem but my feeling is that after looking at the Newton 1.6 examples, which use callbacks even more heavily, it seems like it's not always the best solution, or even needed to have so many callbacks. My problem with the 'ForceAndTorqueCallback' is simply that, it feels redundant. I know that adding a force at any time during the program isn't really good in terms of the physics integrator but, couldn't Newton just store an accumulator for the object which stores all the ApplyForce / ApplyTorque etc and then uses and clears the values during the world update step. That's literally what my code does, storing 2 vectors per object and simply passing them over during the ForceAndTorque callback. It'd speed up the program somewhat and also clean up the general flow of things.

The buoyancy system is another example of this, my view is that it would be a LOT easier to simply define a bounding volume for a "buoyancy region" which newton will then automatically apply buoyancy for using a set of parameters you define for it. The current method is fairly longwinded by comparison and requires; working out what is in water, within the 'NewtonApplyForceAndTorque' callback call 'NewtonBodyAddBuoyancyForce' and finally applying a buoyancy force within that second callback. The Newton 1.6 demos include a version of buoyancy where Newton "triggers" a callback from a material but, I still think being able to define regions is a better method than callbacks. It's redundant to have to keep passing "dFloat fluidDensity, dFloat fluidLinearViscosity, dFloat fluidAngularViscosity" to the buoyancy force EVERY time you call it and also means if you have multiple water volumes your program has to do determine which it is in, (as well as IF it is even in water) - which isn't a huge problem but, again sounds redundant as newton must already be doing some spacial indexing. The callback also has you calculate / pass over the plane equation again and again which realistically probably never changes from 'Up' and you'd only really need to pass over once during creation of the water volume (and possibly have a function to change it if for some reason your water surface changes drastically during gameplay). This may have some problems like the inability to ignore/override or to change things but - I don't really think something like 'fluidLinearViscosity' needs to change on a per frame basis, (or indeed less).

I would propose that perhaps something like:
"CreateBuoyancyRegion(dFloat fluidDensity, dFloat fluidLinearViscosity, dFloat fluidAngularViscosity, dFloat* BuoyancyPlane)"
could be used and work as I described and you could use it for other things besides water and liquids such as, an 'air lift/anti gravity lift' where in game a strong wind carries an object upwards such as the 'Wind Temple' from the famous Zelda series. It could also take the direction of the Newton 1.6 demo and accept a Newton CollisionShape to define the volume.

This post might seem terribly negative and that I'm heavily criticising Newton but that's not my intention, I'm trying to suggest improvements and I'll continue to use Newton as I do believe it's the best free physics system available and I commend Julio for the work he's doing - I'm just worried that it seems less and less like I 'integrate Newton' and more and more like I have to build my program around Newton. Which I suppose is my main concern that it's very easy to make demo's but not so easy to get working nicely with larger more complex projects. I think the callbacks are perhaps leftovers from the original design of Newton.

I think one major thing that needs addressing is "game" specific needs. Stacking up 1000 boxes is very impressive for a physics simulation but, it's rare to round a corner in the 'abandoned research station' to find 100 barrels on top of one another. I do know however that the Newton 1.6 SDK includes an enhanced character controller and vehicle 'joints' which will, I think be of far greater use to a game developer. Newton is also aimed at 'Physics Simulation' so I'm not suggesting make it all games specific but just to try to offer features games developers 'need' rather than the ones that are most impressive.

I know some of the problems mentioned might be due to the design of my program and again, most people who just make demos etc won't see any problem but, please don't post replies telling me alternatives to how I deal with the callbacks or things like "if you're not happy with newton use something else" as that isn't the point I'm making. I just wanted to state I was worried about the direction Newton is taking in it's design such as the direct integration with cal3d, as oppose to a more generic implementation which the developer can then convert to.

Also, as a final note - the new version of Newton is still in beta so.. I'm criticising something that's still in development and may change dramatically and render some of my points invalid but, I'm hoping Julio will see my constructive criticism as it's intended and take something from it as he develops the new version of Newton.

[agi_shi]

The way newton uses callbacks seems to be a limiting factor in my game in that, it forces me to have a lot of static member functions. The alternative is to use global functions or store pointers to other objects in the 'UserData' of a Newton object. I can see that this is a good idea for the material callbacks - such as two objects colliding and I've written functions to deal with that but.. is it really necessary to have the 'ForceAndTorqueCallback' ?

Yes, it allows you to precisely control the force and torque of an object for a single time step. Besides, I don't see the problem. One global function in an anonymous namespace that calls the local member function of the C++ object:

Code: Select all

void phys::body::forceTorque(float timeStep)
{
    addForce(mass() * gravity());
}

// game::character inherits from phys::body
void game::character::forceTorque(float timeStep)
{
    // apply basic forces
    phys::body::forceTorque();

    // apply character-specific forces, such as movement
    vec3 moveForce = _calculateMovementForce(timeStep);
    addForce(moveForce);
}


I'm sure quite a few people won't even see this as a problem but my feeling is that after looking at the Newton 1.6 examples, which use callbacks even more heavily, it seems like it's not always the best solution, or even needed to have so many callbacks. My problem with the 'ForceAndTorqueCallback' is simply that, it feels redundant. I know that adding a force at any time during the program isn't really good in terms of the physics integrator but, couldn't Newton just store an accumulator for the object which stores all the ApplyForce / ApplyTorque etc and then uses and clears the values during the world update step. That's literally what my code does, storing 2 vectors per object and simply passing them over during the ForceAndTorque callback. It'd speed up the program somewhat and also clean up the general flow of things.

You're missing the point. Your game can and should be running at a different interval from the physics. If the physics are running at 60 FPS and your game at 30 FPS, and you apply forces globally, you'll get unexpected behaviour. One of your callbacks will apply your 30 FPS force on the first 60 FPS physics step (not good). The second will apply no force to the second 60 FPS physics step. Using the callback allows you to control the force and torque precisely per physics step, and not per game step.

The buoyancy system is another example of this, my view is that it would be a LOT easier to simply define a bounding volume for a "buoyancy region" which newton will then automatically apply buoyancy for using a set of parameters you define for it. The current method is fairly longwinded by comparison and requires; working out what is in water, within the 'NewtonApplyForceAndTorque' callback call 'NewtonBodyAddBuoyancyForce' and finally applying a buoyancy force within that second callback. The Newton 1.6 demos include a version of buoyancy where Newton "triggers" a callback from a material but, I still think being able to define regions is a better method than callbacks. It's redundant to have to keep passing "dFloat fluidDensity, dFloat fluidLinearViscosity, dFloat fluidAngularViscosity" to the buoyancy force EVERY time you call it and also means if you have multiple water volumes your program has to do determine which it is in, (as well as IF it is even in water) - which isn't a huge problem but, again sounds redundant as newton must already be doing some spacial indexing. The callback also has you calculate / pass over the plane equation again and again which realistically probably never changes from 'Up' and you'd only really need to pass over once during creation of the water volume (and possibly have a function to change it if for some reason your water surface changes drastically during gameplay). This may have some problems like the inability to ignore/override or to change things but - I don't really think something like 'fluidLinearViscosity' needs to change on a per frame basis, (or indeed less).

I would propose that perhaps something like:
"CreateBuoyancyRegion(dFloat fluidDensity, dFloat fluidLinearViscosity, dFloat fluidAngularViscosity, dFloat* BuoyancyPlane)"
could be used and work as I described and you could use it for other things besides water and liquids such as, an 'air lift/anti gravity lift' where in game a strong wind carries an object upwards such as the 'Wind Temple' from the famous Zelda series. It could also take the direction of the Newton 1.6 demo and accept a Newton CollisionShape to define the volume.

Why lose the extra control? You can easily form a quick environment around the low-level buoyancy, and, in fact, you should form such an environment. What if dropping a power up into the water made it behave as glue? Woops, seems like you'll have to now recreate the whole volume.

This post might seem terribly negative and that I'm heavily criticising Newton but that's not my intention, I'm trying to suggest improvements and I'll continue to use Newton as I do believe it's the best free physics system available and I commend Julio for the work he's doing - I'm just worried that it seems less and less like I 'integrate Newton' and more and more like I have to build my program around Newton. Which I suppose is my main concern that it's very easy to make demo's but not so easy to get working nicely with larger more complex projects. I think the callbacks are perhaps leftovers from the original design of Newton.

Demos, sure, but people are using Newton in a lot more than demos. Just check out the showcase forum.

I think one major thing that needs addressing is "game" specific needs. Stacking up 1000 boxes is very impressive for a physics simulation but, it's rare to round a corner in the 'abandoned research station' to find 100 barrels on top of one another. I do know however that the Newton 1.6 SDK includes an enhanced character controller and vehicle 'joints' which will, I think be of far greater use to a game developer. Newton is also aimed at 'Physics Simulation' so I'm not suggesting make it all games specific but just to try to offer features games developers 'need' rather than the ones that are most impressive.

Newton is for fast, accurate physics. If you check out the showcase forum, you'll notice its used for a lot more than just games.

I know some of the problems mentioned might be due to the design of my program and again, most people who just make demos etc won't see any problem but, please don't post replies telling me alternatives to how I deal with the callbacks or things like "if you're not happy with newton use something else" as that isn't the point I'm making. I just wanted to state I was worried about the direction Newton is taking in it's design such as the direct integration with cal3d, as oppose to a more generic implementation which the developer can then convert to.

Also, as a final note - the new version of Newton is still in beta so.. I'm criticising something that's still in development and may change dramatically and render some of my points invalid but, I'm hoping Julio will see my constructive criticism as it's intended and take something from it as he develops the new version of Newton.

I think it's due to the design of your program. I never deal with newton directly, it's all abstracted away in a C++ object oriented interface - with which Newton integrates very cleanly, no inheriting from "actors" or any stupid stuff like that.

[Andy Price]

Yes, it allows you to precisely control the force and torque of an object for a single time step. Besides, I don't see the problem. One global function in an anonymous namespace that calls the local member function of the C++ object:

This 'global function' that does the calling then needs access to member functions of the class, you ca achieve that by storing pointers to object but, since objects are stored in arrays within their manager class, the pointer changes. I have multiple types of "object" within my code, I don't simply have 1 object type. Again, the method you suggest is fine for a demo but less appropriate for more complex projects.

You're missing the point. Your game can and should be running at a different interval from the physics. If the physics are running at 60 FPS and your game at 30 FPS, and you apply forces globally, you'll get unexpected behaviour. One of your callbacks will apply your 30 FPS force on the first 60 FPS physics step (not good). The second will apply no force to the second 60 FPS physics step. Using the callback allows you to control the force and torque precisely per physics step, and not per game step.

My game does run with different timesteps but I'll admit I didn't think of this problem. My game's "update" step is the same as the physics update speed (60fps) so I'd never have noticed this. I don't know how your example would come about though since, if your "game" was running at 30fps - do you mean everything in the game or just the physics updates? If that's the case then, won't it still work since you'd only be calling NewtonUpdateWorld 30 times (although that would be too slow for a proper timestep). I suppose you mean running the game logic at a different speed to the rate you call NewtonWorldUpdate. I still don't entirely think the problem you described would happen since, the programs "physics timestep" would be the same rate you apply force and the same rate you called NewtonWorldUpdate, regardless of if it's 30 or 60 or whatever. I can't see why you'd be applying physics forces during a different timestep to updating the newton world. Plus, everyone has already had to think in this synchronised method because of the way Newton currently functions so it wouldn't be a huge shift - in fact the only change you'd need to make to current programs would be to manually call the ForceAndTorque callback and it'd work exactly the same. I don't know why you'd need to adjust the physics any finer than a 'game step'. If you've calculated how much to move a box that 'game step', why would you then want to change it during the physics update?

Why lose the extra control? You can easily form a quick environment around the low-level buoyancy, and, in fact, you should form such an environment. What if dropping a power up into the water made it behave as glue? Woops, seems like you'll have to now recreate the whole volume.

You wouldn't lose it, nor would you need to recreate the volume to make changes. As I said in my post you could simply have a function to change the properties. Something like "SetVolumeViscocity()" would work. The counter argument is - why do you need to give Newton the information every single physics update, 'just in case' that glue powerup has fallen in. It also means the application is keeping track of all the extra data related to the volume which may not be easily accessible in a static callback without singletons / pointer casting. You wouldn't lose any control whatsoever and it would function almost exactly as the old system does.

Demos, sure, but people are using Newton in a lot more than demos. Just check out the showcase forum.

I know people make more than demos and I think you're missing the entire point of my post.

Newton is for fast, accurate physics. If you check out the showcase forum, you'll notice its used for a lot more than just games.

Actually, newton is called "Game Dynamics" and I know Julio likes the fact that it is 'accurate' as opposed to the more 'fake' physics solutions, it is being aimed at games. Again, I think you're missing the entire point of my post.

Erm, I did say I know it's used for more than games. The fact is though, it's called "Newton Game Dynamics" - which was my point. It's used for more than games yes, and I said I knew that BUT, it does aim itself towards games as well. With that in mind, the fact that things like a decent method of controlling a character hasn't appeared until version 1.6

I think it's due to the design of your program. I never deal with newton directly, it's all abstracted away in a C++ object oriented interface - with which Newton integrates very cleanly, no inheriting from "actors" or any stupid stuff like that.

Some of the problems are possibly due to the design of my program but the again It'd be nice if Newton without being forced to conform to certain rules or methods of operation. Things like storing pointers in the userdata is all fun but, it can also lead to nasty problems and completely falls down on a system not using linked lists or a similar memory method. The fact I use arrays renders that method useless - and before I get people saying "don't use arrays" - I will continue to use arrays as they allow a lot of improvements over lists and I believe they simply are a better solution. I'm posting about Newton and how I see it, not so that people can criticise how I decide to write my games. I don't deal with Newton 'directly' either in that sense but, I'm writing the entire "engine" for my games so, I'm also the one who is creating the "C++ object oriented interface" which means I'm dealing with everything from high to low level and it does not interface entirely "cleanly", you can hide everything behind the scenes but some things require access to the forefront, such as all the callbacks. I don't know where the "inheriting from "actors" or any stupid stuff like that" comes from so I'll ignore that bit.

I think you've missed the entire point of my post which is a shame but at least it wasn't massively "flaming" which is what I expected. I'm hoping Julio will reply at some point as the main reason I posted was that I'd like to hear his views.

[agi_shi]

I know you're waiting for Julio's reply, but I still wish to make my point.

This 'global function' that does the calling then needs access to member functions of the class, you ca achieve that by storing pointers to object but, since objects are stored in arrays within their manager class, the pointer changes.

What? What do you mean? How does an array change the pointer itself?

Code: Select all

phys::body::body(const world &_world)
{
    /* create body */
    NewtonBodySetUserData(_body, this); // 'this' owns the Newton body, the this/body pair will never change, regardless of your array storage
}

void someNewtonCallback(void *userData)
{
    body *_body = static_cast<body*>(userData);
    _body->someNewtonCallback(); // propagate down
}

void phys::body::someNewtonCallback()
{
    // callback is issued for this body
}


I have multiple types of "object" within my code, I don't simply have 1 object type. Again, the method you suggest is fine for a demo but less appropriate for more complex projects.

Me neither. You're missing the point. Create a base physics body type, and inherit your other objects from it. Did you completely ignore my character example? This is my object hierarchy:

Code: Select all

phys::body
                         >      game::physEntity /* physics based entity */     >     game::character /* physics based character entity */
game::entity


etc. etc.
Simply make the callbacks virtual, and override the callbacks in higher classes. Again, see my character example in my first post.

My game does run with different timesteps but I'll admit I didn't think of this problem.

I used to use your method of globally applying the forces, but once I added mouse-dragging I received very choppy, inaccurate results. After migrating the dragging force calculations from game-steps to physics-steps the choppiness went away. Personal experience.

Things like storing pointers in the userdata is all fun but, it can also lead to nasty problems and completely falls down on a system not using linked lists or a similar memory method. The fact I use arrays renders that method useless - and before I get people saying "don't use arrays" - I will continue to use arrays as they allow a lot of improvements over lists and I believe they simply are a better solution.

I fail to see your point. How does storage (storage of your objects) cause problems for pairs (C++ object <--> Newton body)? What does an array or linked list have anything to do with the objects they store? I don't use either. I use an std::map of all of my entities, of which some are physics based, others are not. How you store your objects should not affect the objects themselves, I think you should rethink your design.

some things require access to the forefront, such as all the callbacks

Sign of bad design. Aim to have as little dependencies as possible. Again, make use of C++'s features - mainly, inheritance and virtual functions. Callbacks can be propagated up the inheritance chain by using virtual functions, as I showed you in my first post.

With that in mind, the fact that things like a decent method of controlling a character hasn't appeared until version 1.6

A decent method of controlling a character has been in there since the beginning, and it's called "forces". Honestly, I'm not too fond of the character controller in 2.0, I use my own - it allows wall walking, sliding, stair climbing, and so on.

[Andy Price]

I know you're waiting for Julio's reply, but I still wish to make my point.
...removed code...
What? What do you mean? How does an array change the pointer itself?

I mean that when the array is reallocated every pointer from physics body UserData to array locations becomes invalid.

Me neither. You're missing the point. Create a base physics body type, and inherit your other objects from it. Did you completely ignore my character example? This is my object hierarchy:

I haven't ignored anything you said but, it wasn't addressing the problem I was trying to illustrate. You've ignored large sections of my original post simply to pick on 1 thing you don't like.

I used to use your method of globally applying the forces, but once I added mouse-dragging I received very choppy, inaccurate results. After migrating the dragging force calculations from game-steps to physics-steps the choppiness went away. Personal experience.

I've never had any problems, probably because my 'update' loop is the same as the physics updates but I'd suggest you did it wrong and used the method you suggested in your last post which would have the same problem I described.

I fail to see your point. How does storage (storage of your objects) cause problems for pairs (C++ object <--> Newton body)? What does an array or linked list have anything to do with the objects they store? I don't use either. I use an std::map of all of my entities, of which some are physics based, others are not. How you store your objects should not affect the objects themselves, I think you should rethink your design.

Er, my design is fine. It affects it massively if you're using the pointer from the UserData in a physics body. It won't work properly with arrays since any time it's reallocated they all become invalid. You're totally misinterpreting what I'm saying, especially when you ask things like "What does an array or linked list have anything to do with the objects they store?".

Sign of bad design. Aim to have as little dependencies as possible. Again, make use of C++'s features - mainly, inheritance and virtual functions. Callbacks can be propagated up the inheritance chain by using virtual functions, as I showed you in my first post.

Again, no it's not 'bad design'.. even inheriting and virtual functions don't resolve the problem in the way I mean. Plus they're slow and force a design method upon you.

A decent method of controlling a character has been in there since the beginning, and it's called "forces". Honestly, I'm not too fond of the character controller in 2.0, I use my own - it allows wall walking, sliding, stair climbing, and so on.

If that were true the forums wouldn't be covered with people asking how to control characters. It's very 'work it out yourself' at the moment. Forces will work but, they're not a 'perfect' solution as games want 'non-realistic' control of objects.

I'm sorry that I don't address every point you make but, all you seem to do is tell me my design is flawed.. which is exactly what I said I didn't want. You are definitely not understanding what I'm saying, especially the way you're talking about how you think I've integrated Newton, this might partly be because I haven't explained everything I've done but - it's irrelevant, I didn't post for you to pull apart how I do things. The bottom line is you do it your way and I'll do it mine, I find arrays superior to messing about with std containers or linked lists so I choose to use them.. that doesn't make my design 'wrong', I could criticise your design heavily but, it doesn't serve any purpose so i don't see why you feel the need to do so or what exactly your "point" is. This is sort of why I said I'm waiting to see if Julio replies as oppose to just other forum users who just want to tell me my way is terrible and their way is great. Sorry if that sounds aggressive but, I did say that I specifically didn't want the kind of posts you're making that just seem critical of me for no good reason - I appreciate your suggestions though.

My intention wasn't to say Newton 'has' to do it this way or to suggest my way is superior but, merely to suggest as a possibility for Julio to consider as Newton is still being developed and so isn't set in stone yet.

[Rob]

I have multiple types of "object" within my code, I don't simply have 1 object type. Again, the method you suggest is fine for a demo but less appropriate for more complex projects.

If you have more than one object type that needs to wrap a Newton body, then you're doing it wrong, and need to rethink your coding practices. My stuff has no shortage of complication, but whether it's a box stacking demo or the biggest game in the world, you still don't need to, and should ideally never, write the same code twice. The heavy use of callbacks is not bad, it's not good either, but it's the way it is in Newton, and it works well with it's architecture and goals. Callbacks are quite standard, and a generic pointer is the standard way to communicate a context with the application.

Some of the problems are possibly due to the design of my program but the again It'd be nice if Newton without being forced to conform to certain rules or methods of operation. Things like storing pointers in the userdata is all fun but, it can also lead to nasty problems and completely falls down on a system not using linked lists or a similar memory method. The fact I use arrays renders that method useless - and before I get people saying "don't use arrays" - I will continue to use arrays as they allow a lot of improvements over lists and I believe they simply are a better solution.

You are very new to programming, it seems (sorry, not trying to offend you, just seems impossible that this isn’t the case). Most applications use pointer arrays, experienced developers do not use instance arrays for anything beyond simple structures or primitives, because they allow no referencing or derivation and are simply bound to fail (as you are clearly experiencing). You are essentially coming here and asking why Newton doesn’t let you do things the wrong way, you should get used to people telling you to simply do it the right way.

And FYI, every API forces you to conform to their rules.

[Andy Price]

I have multiple types of "object" within my code, I don't simply have 1 object type. Again, the method you suggest is fine for a demo but less appropriate for more complex projects.

If you have more than one object type that needs to wrap a Newton body, then you're doing it wrong, and need to rethink your coding practices. My stuff has no shortage of complication, but whether it's a box stacking demo or the biggest game in the world, you still don't need to, and should ideally never, write the same code twice. The heavy use of callbacks is not bad, it's not good either, but it's the way it is in Newton, and it works well with it's architecture and goals. Callbacks are quite standard, and a generic pointer is the standard way to communicate a context with the application.

Some of the problems are possibly due to the design of my program but the again It'd be nice if Newton without being forced to conform to certain rules or methods of operation. Things like storing pointers in the userdata is all fun but, it can also lead to nasty problems and completely falls down on a system not using linked lists or a similar memory method. The fact I use arrays renders that method useless - and before I get people saying "don't use arrays" - I will continue to use arrays as they allow a lot of improvements over lists and I believe they simply are a better solution.

You are very new to programming, it seems (sorry, not trying to offend you, just seems impossible that this isn’t the case). Most applications use pointer arrays, experienced developers do not use instance arrays for anything beyond simple structures or primitives, because they allow no referencing or derivation and are simply bound to fail (as you are clearly experiencing). You are essentially coming here and asking why Newton doesn’t let you do things the wrong way, you should get used to people telling you to simply do it the right way.

And FYI, every API forces you to conform to their rules.

I've been programming for 11 years so I'm not new to it but, there's always something you don't know. I feel you've not really said anything to do with the point of this topic except attack my programming style.. which doesn't really add anything to the point I was trying to make in my first post. You're trying to tell me that every single professionally developed game is programmed in the style you approve of, but I know for a fact it isn't the case. Your post is simply uncalled for and I think you should just go elsewhere if your attitude is "get used to people telling you the right way of doing it" - so far you haven't told me the "right" way, just your own opinion. The "right" way varies between circumstance and even the "experienced developers" would know that - and in my case, arrays are superior than the alternatives. Arrays aren't "bound to fail" and work a lot better than the alternative in my experience.

..and yes, you are forced to use whatever methods an API exposes, but that is NOT the same as being forced to conform to their rules.

This discussion has gone way off topic and is now just 2 people pointlessly trying to criticise the way I've programmed my game. I'm hoping Julio will just delete this topic and talk to me in private message instead since it seems I'm just going to get a load of petty replies telling me to do it 'their way' and it'll degenerate into an arguement over programming style and each person trying to back their own method. Again, sorry if this seems aggressive but I'm so sick of these petty discussions forming every time someone tries to make a valid point and people can't just be objective about it.

[Rob]

I feel you've not really said anything to do with the point of this topic except attack my programming style.. which doesn't really add anything to the point I was trying to make in my first post. You're trying to tell me that every single professionally developed game is programmed in the style you approve of, but I know for a fact it isn't the case.

No, I’ve seen my share of poorly designed code in professional games, and quite frankly I’ve written bad code too, we all have (I'd like to think I've learned from it). The point you fail to recognize is that it’s NOT a matter of programming style, it’s not syntax, it’s method, and your method is wrong because, by your own admission, it impairs your ability to communicate with an API using standard methods. I could try to speak English with my own made up words, and when communicating with myself that may be fine, but with regards to communicating with others, it’s wrong.

The point is the API is written this way because it works well with the standard way people write their applications, if you want to do things in a non-standard way, then these are the consequences.

..and yes, you are forced to use whatever methods an API exposes, but that is NOT the same as being forced to conform to their rules.

With regards to communicating with those methods, it absolutely is the same. You could stick to your method of storing data, and frankly, you can still make it work, you just have to store indices instead of pointers in the userdata. Of course, by not using pointers eventually you’re going to have a bunch of different types of lists complicating that process, but that’s entirely your choice, if you truly haven’t seen the limitations of only using instance arrays after 11 years I’m not going to change your mind. Regardless, this method by no means restricts what you do outside of communicating with Newton, which is what all APIs do.

Again, sorry if this seems aggressive but I'm so sick of these petty discussions forming every time someone tries to make a valid point and people can't just be objective about it.

Sadly, I feel both mine and agi_shi’s posts were meant to be informative, and you would save yourself a lot of time if you thought about why so many people do things this way, perhaps in a few days when you cool off you can re-read it and get something positive from it. Perhaps there is a political way to tell someone they’re choices are bad while still making them feel warm and fuzzy inside about them, but I don’t know that method, I was just giving you what is, BY FAR, the path of least resistance. Programming with APIs does not reward individuality, not by a long shot.

[Andy Price]

This'll be the last post I make on here so anything after won't be seen by me. They're not 'informative' or neither of you would feel the need to argue the point, it seems simply critical/negative and the way it's pursued is definately more than merely 'informative'. I'm not 'upset' by it, nor do I need to 'cool down' - which feels like a deliberate attempt to suggest I'm somehow being overemotional just because I don't agree with you. If you were objective, in any way, you wouldn't be talking about my programmnig methods and would simply have responded to the points I made in my first post. I suggest it is you who is getting emotionally involved trying to argue the methods you favour and perhaps needs to come back to this tomorrow and simply read the points I made in my first post also, I don't care how you put across your argument but at least I've made efforts not to come across as rude. I'm saying there is no reason for you to be criticising me, which is the only thing you are doing. There aren't "so many people" who do it the way you suggest, again, it's a gross generalisation. My code isn't "poorly designed by my own admission" and you yourself said the callback system is both good and bad so, you can't now change your view to entirely blame me.

I stated in practically every post that I did NOT want your view on my programming methods but, you both commented on nothing but and totally ignored what I was originally saying. I made a few different points about possible ideas for Newton in my first post and you haven't touched a single one of them, you're simply telling me my programming method is totally wrong but.. it's worked for the projects I've been involved in so it can't be all bad.

Topic ended.

[agi_shi]

I still don't understand how an array is any different from a linked list or an STL container in terms of invalidating pointers

Oh, the OP probably meant something like this:

Code: Select all

body *bodies = new body[9001]; // over 9000!!! :D
delete[] bodies; // pointers invalidated


But, I mean ... if you delete the bodies, it only makes sense for the pointers to be invalidated - after all, the body won't exist any more

Regarding Newton's style, assuming you end up reading this, Julio: Personally, I like Newton's style. But, maybe, there are some things regarding the callbacks that can be changed. For example, instead of having a callback for each time a body is moved/rotated, NewtonUpdate() can return a list of updated bodies, and possibly their new matrices. That way the code won't jump all over the place from inside NewtonUpdate() and might make better use of the cache. Just throwing random ideas out there.

[Rob]

I still don't understand how an array is any different from a linked list or an STL container in terms of invalidating pointers

Pretty sure what he's talking about is using a container class to store instances of the structure, so that asking for 5 instances of a 100 byte sized structure gives you one, 500 byte memory block. So, when you ask the container class to give you a sixth instance, it has to reallocate the memory block to hold it, thus moving the other 5 instances. This structure has positive impact on speed in some situation due to a potentially more cache friendly layout (which would likely be immeasurable in this scenario), but since it naturally breaks referencing and derivation nobody does it for remotely complicated applications.

[agi_shi]

Right, but unless you're using POD types (defeats the purpose of C++), reallocating will cause the destruction and reconstruction of the C++ objects. Invalidating the pointers won't matter much considering you're invaliding the rest of the C++ objects by calling their destructors/constructors.

[Rob]

Right, but unless you're using POD types (defeats the purpose of C++), reallocating will cause the destruction and reconstruction of the C++ objects. Invalidating the pointers won't matter much considering you're invaliding the rest of the C++ objects by calling their destructors/constructors.

Right, his implementation defeats the purpose of C++. He's seemingly using structs, not classes (IOW, class in name only, but not using any features of a class).

[Julio Jerez]

...
I just wanted to state I was worried about the direction Newton is taking in it's design such as the direct integration with cal3d, as oppose to a more generic implementation which the developer can then convert to.

I just want to say, what make you think newton will do a direct integration with cal3d?
I made a demo to test a feature, and the only free animation system I found was cal3d.

If you read the thread about Archemedia, it said they Newtp will feature and pose base animation system the will be independent of graphics.

Basically the system will work in the exact same way newton work,
you set the animation and the update function will update the matrices of you bone.
The is coming with next beta, and I have already working with the vehicle.

Any application can use this animation system as long as it is matrices, or euler angles rt quaternions a to update skeleton. The animation system do not ne to know about how the skeleton is configure.

The anitation system is independent of the physics, and can be use as standalone.
Id not take care of the graphics system, like Cal3d or Granny.

But when working with the physics it is more than just an animation system but for that I will let you judge.

[Andy Price]

I thought the cal3d was 'more than it is' after reading some of you posts on the forum such as;

You might be in luck; the newer version is implementing a full IK system with motion adaptation and parametric control. We are using Cal3d, and
...
The integration with Cal3d is already done although I am having some problems with Cal3d where is build in debug but crashes in release.

Where you've said things like "the integration with Cal3d" it reads as newton is being directly integrated with cal3d but now you've explained more I see this isn't what you meant so you can ignore that.

Just a last note to agi_shi and rob, I'm not doing any of the things you think and it's stupid to be so critical about the assumptions you yourselves make about my work.