Comments (7)
Not agreeing or disagreeing, just making some notes:
- Code in Body::Body I see that the sweep is initialized from the
location
andangle
member variables of the givenBodyConf
. This wouldn't appear to, by-itself, preserve the state of the sweep'spos
,localCenter
, noralpha0
member variables. - Code in Body::Body initializes
m_invMass
but not to a specific inverse mass specifiable by the givenBodyConf
.
from playrho.
With Sweep
and others that are their own strong type, I'm inclined to call the function just Use
- so like .Use(sweep)
. At least that's more consistent with what I've been doing for unique/strong types. I imagine that'd be preferable to you too, no?
from playrho.
Not agreeing or disagreeing, just making some notes:
- Code in Body::Body I see that the sweep is initialized from the
location
andangle
member variables of the givenBodyConf
. This wouldn't appear to, by-itself, preserve the state of the sweep'spos
,localCenter
, noralpha0
member variables.- Code in Body::Body initializes
m_invMass
but not to a specific inverse mass specifiable by the givenBodyConf
.
Yes, these were the things I noticed as well that could diverge after the body has been created and modified, why I had to set them manually after the BodyConf
to preserve the state.
With
Sweep
and others that are their own strong type, I'm inclined to call the function justUse
- so like.Use(sweep)
. At least that's more consistent with what I've been doing for unique/strong types. I imagine that'd be preferable to you too, no?
Works either way for me!
from playrho.
location
and angle
of BodyConf
are two of the fields for the Body
Sweep
. Adding the entire Sweep
data to BodyConf
I'm considering as something that could be done by adding the missing state as additional member variables of BodyConf
, or by subsuming location
and angle
into a Sweep
member variable instead.
A downside I can think of for adding the additional state of Sweep
via additional member variables is the additional builder functions then that need to be also added. An upside of course is this wouldn't require changes to any users' code who are relying on these interfaces already.
The master branch is not intended to be as stable though unlike release branches.
An upside to subsuming location
and angle
members of BodyConf
with instead a Sweep
variable would be gaining the use of another strong type instead of these two that are only strong with BOOST units support enabled. Another upside is in this reducing the number of builder function interfaces then to support its use.
from playrho.
I just merged changes which I believe resolve all of the missing properties issue. See the PR #552 for details. Turned out to be more work than I had expected.
PlayRho had lots of direct uses of the BodyConf
location
and angle
member variables which had to be removed to fully support Sweep
and that using code had to be updated to use functions instead to maintain the intended state settings.
Another impediment for me in this changes, was considering the semantics of the replaced/added state and ensuring sensible variance per the BodyType
and other possible settings. I keep thinking I'd save myself headache by switching BodyConf
to instead be like an alias to std::variant<StaticBodyConf, KinematicBodyConf, DynamicBodyConf>
. Where, logically speaking, KinematicBodyConf
is all the state of StaticBodyConf
plus velocity oriented state, and DynamicBodyConf
is all the state of KinematicBodyConf
plus acceleration oriented state.
Please let me know if you think I may have missed any state.
from playrho.
Marking this as closed/resolved for now.
from playrho.
I'm testing this out now and I'm having a small issue with it. I removed the calls to UseLocation
and UseAngle
and replaced them with UseSweep
. However, the resulting body doesn't have the same location, or "m_xf
", as the one I serialized it from. It seems that the value of m_xf
is set from the pos0
from the sweep, done from the GetTransformation
here:
Transformation GetTransformation(const BodyConf& conf) noexcept
{
return {conf.sweep.pos0.linear, UnitVec::Get(conf.sweep.pos0.angular)};
}
when the value of x_mf
in the old body is the value of pos1
of the sweep. And I can't call UseLocation
to fix this, because then I will loose the pos0
from the sweep.
I also had to set resetMassData
to false, because otherwise I will also loose the pos0
from the sweep, but I guess I always have to avoid this function if I want an exact copy of a body?
from playrho.
Related Issues (20)
- ToSigned shouldn't be under playrho::d2
- Bug in cmake install: not all necessary headers get installed
- API documentation publication not part of CI HOT 1
- Make use of new allocator stats support
- Testbed, UnitTests, Benchmark require git recursive clone
- Pass values from the ShapeConf to other (sub)shape configs HOT 2
- Set multiple shapes to BodyConf at once HOT 3
- No GetShapes function HOT 4
- Incomplete equality operator for Body HOT 2
- Extend WorldBody methods HOT 5
- Should caches be compared in the equality operator for the world? HOT 2
- Missing getters and setters for flags and inv_dt0 (for serialization purposes) HOT 1
- Ability to manually create a Contact (for serialization purposes) HOT 2
- Wrong position for transformation HOT 5
- No equivalent "IsDestroyed" method in World interface HOT 6
- Incorrect manifolds when deserializing/recreating the World state HOT 2
- GetContacts GetBodies GetJoints but no GetShapes inconsistency
- Just two very similar functions HOT 4
- Make UnitVec initializing constructor public HOT 15
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from playrho.