Sign in to follow this  
AverageJoeSSU

PhysX var types and C++ types?

Recommended Posts

Can you cast these harmoniously? for example.... my engine has a glVector4 class... which is nearly the same thing as a NxVec4 minus the fancy inline and such stuff (same with my matrix classes). my matrix class is just a float[16] column major array address.... which works in passing the pointer to opengl. if the PhysX API is expecting a 4x4 matrix* and I pass that pointer it should be ok right? Does this work for other types like NxVec3 (float[3]) and NxReal (float). I store all of my mesh data in native variable types, and dont want to have to rewrite or use theirs. thanks, hope this makes sense -j EDIT: i know this seems like a PhysX forum topic... but to be honest nobody responds on that forum like this one, which is uber awesome. =)

Share this post


Link to post
Share on other sites
If the memory signature of the objects are identical (same member variables of the same primitive types in the same order and with the same alignment), then technically you should be able to reinterpret_cast between them and the different API's would operate on them appropriately. And that is a way to do a micro performance optimization in your code. (WARNING: that isn't necessarily true for any class or struct that has non-primitive members...gets complicated.) It might seem like you're streamlining your code and adding elegance....if you think so, read on!

SO...I recommend that you do NOT do this! Why? First, it obfuscates the code. It will be hard for anyone else to figure out what is going on if they look at it. You'd have to heavily comment to make it readable. Even if you are the only developer, in 6 months without proper commenting, you'd struggle a bit to figure out what is going on. In 2 years, all memory of it would be lost and you'd look at the code and think you must have been crazy at the time. Further, you would be locking the code to specific versions of the two API's, or assuming that the two API's won't change in the future. Which might be a bad assumption.

A cleaner way to do this, without getting all uber-oriented, would be to just create some simple adapter functions or macros that map between native variable types and the different API's. You do incur a bit of runtime performance loss by having to convert between types, but it tends to be a micro optimization. But merely isolating the conversion into dedicated functions will make the code easier to maintain in the case of API changes and less confusing. I would recommend looking at Pete Isensee's GDC presentations for numerous practical areas to spend time optimizing for performance, if that is one of your concerns (http://www.tantalon.com/pete.htm).

Share this post


Link to post
Share on other sites
Yeah...

It indeed is micro optimization, however the main reason I bring this up is trying to better understand how Nvidia wants the Dev to handle data between PhysX and a renderer.

I agree that functions are the way to go.

I would like to attempt fluid at some point, and hope to have a firm grasp of this by the time I get there. simulating a couple thousand fluid particles in hardware and then rendering them in my renderer is a bit scary sounding.

Oh how I wish bindless graphics could apply to this somehow.

Thanks for the advice... I will give that a go.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this