Jump to content
  • Advertisement
Sign in to follow this  
tom_mai78101

Porting a physics engine: What do these variables stand for?

This topic is 827 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm currently porting / learning C++ code of a lightweight physics engine over to a C code variant engine. The lightweight physics engine is qu3e, written by Randy Gaul.

Source code

 

While porting the code over, I spot a few things that I'm confused about. Given that there are no comments that explain what these variables are for, and doesn't say what their meanings are, I am asking for help to explain the meaning and intentions for these variables.

 

_____________________________________________________

 

Here's one.

 

I know Feature Pairs in a physics engine refers to "The closest pair of features (edge or vertex)". So I am confused about what

inR, inI, outR, and outI

stands for. What do these 4 variables have to do with Feature Pairs?

 

_____________________________________________________

 

This is another one.

 

In this context, I know this struct is referred to as the Axis-Aligned Bounding Box struct, or AABB. Even with that in mind, I still have no idea what the

e

variable represents in the AABBes. Is there something important about the letter "e", as in, it could be some mathematical constant? Or is it energy?

Edited by tom_mai78101

Share this post


Link to post
Share on other sites
Advertisement

Were comments added after the thread was started? Because there are comments explaining them right in those areas:

 

[source]// in stands for "incoming"

// out stands for "outgoing"

// I stands for "incident"

// R stands for "reference"[/source]

 

[source]// extent, as in the extent of each OBB axis[/source]

 

But yeah, those variable names... huh...

Share this post


Link to post
Share on other sites

Were comments added after the thread was started? Because there are comments explaining them right in those areas:

 

[source]// in stands for "incoming"

// out stands for "outgoing"

// I stands for "incident"

// R stands for "reference"[/source]

 

[source]// extent, as in the extent of each OBB axis[/source]

 

But yeah, those variable names... huh...

 

Yep, just added them in. Unfortunately I didn't come up with the names for a lot of these things. Extent. Incident. Bleh. Also it's much easier to just derive things on paper and copy down into the code the equations, so a lot of abstract symbols come up, like e and whatnot. Apologies if any of that is confusing.

Share this post


Link to post
Share on other sites

Were comments added after the thread was started? Because there are comments explaining them right in those areas:
 
[source]// in stands for "incoming"
// out stands for "outgoing"
// I stands for "incident"
// R stands for "reference"[/source]
 
[source]// extent, as in the extent of each OBB axis[/source]
 
But yeah, those variable names... huh...

 
Yep, just added them in. Unfortunately I didn't come up with the names for a lot of these things. Extent. Incident. Bleh. Also it's much easier to just derive things on paper and copy down into the code the equations, so a lot of abstract symbols come up, like e and whatnot. Apologies if any of that is confusing.

Hopefully, some of the issues/pull requests are handled. I noticed there is one which resolved some other confusing parts in your code, but I have no idea if it is better.

Thanks again.

Share this post


Link to post
Share on other sites

 

Were comments added after the thread was started? Because there are comments explaining them right in those areas:

 

[source]// in stands for "incoming"

// out stands for "outgoing"

// I stands for "incident"

// R stands for "reference"[/source]

 

[source]// extent, as in the extent of each OBB axis[/source]

 

But yeah, those variable names... huh...

 

Yep, just added them in. Unfortunately I didn't come up with the names for a lot of these things. Extent. Incident. Bleh. Also it's much easier to just derive things on paper and copy down into the code the equations, so a lot of abstract symbols come up, like e and whatnot. Apologies if any of that is confusing.

 

Yeah, when doing straight up math, I often do the same, and fall back on short math variable names over long variable names like fMomentum or whatever.  It makes it a bit easier to see the formula.  A half measure is a really long parameter name that gets immediately reassigned to a short local name, the nice part then is that someone using an intellisense or looking at the header file can easily grasp the full meaning, but the actual code still resembles the math.  The compiler will optimize out the local param.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!