new display method quite confusing

Discuss any questions about BEPUphysics or problems encountered.
sueds
Posts: 43
Joined: Tue Feb 05, 2008 10:40 am

new display method quite confusing

Post by sueds » Tue Apr 22, 2008 9:40 pm

hello,

Sorry to drag this point again and since nobody complain about it would be me the problem but I think the new display method is quite uneasy compare to the old one. I mean I do understand the need of instancing and stuff but it would really nice to be able to simply add a shape to the box like we did in the last version with a single line of code. I was also thinking that it would be nice to debug the rigid bodies with wireframe render. Because sometime you can't see the offset of the object clearly.

I don't know what the other think about that but I really though the last way to display and with some wireframe rendering it would be the best

User avatar
Zukarakox
Not a Site Admin
Posts: 426
Joined: Mon Jul 10, 2006 4:28 am
Contact:

Re: new display method quite confusing

Post by Zukarakox » Tue Apr 22, 2008 9:46 pm

Display methods are open source, so you can edit them yourself to suit your liking.
i has multiple toes

Norbo
Site Admin
Posts: 4884
Joined: Tue Jul 04, 2006 4:45 am

Re: new display method quite confusing

Post by Norbo » Tue Apr 22, 2008 10:39 pm

I'm not quite sure what you're referring to in terms of external usage of the renderer, adding display objects is still a one-line operation- addEntity for example. I tried to keep the 'external' references essentially the same when I created the new GPU instancing system. I would say the internal code of the entity drawer has gotten a good bit more complicated, but most of that doesn't need to be fiddled with (just like the previous 'in-engine' renderer didn't offer source). I do plan to offer additional features (dropping down the quality, wireframe, things like that) in the demos graphics update, but it might take a few weeks for that to make it out the door due to some other work I need to attend to.

sueds
Posts: 43
Joined: Tue Feb 05, 2008 10:40 am

Re: new display method quite confusing

Post by sueds » Tue Apr 22, 2008 11:55 pm

yes you are right but it's just that even if build my own method editing the entity drawer It's not handy at it was. I just wanted to mention that. is like having every class for every entity, it easy to set up yourself but not very handy if you just want check something when you game is already on track. I've build my own ray/ bounding box drawer and I can tell you when you are checking more than one object at the time again and again you can start to being crazy if the system is not hanndy( mine wasn't). So is not just about being lazy it really bother me since I'm gonna use the collision detection for event and specific use in all my level, so I might spend a lot of time checking if my object shape match to the rigid bodies.

norbo don't worry about this stuff you are doing a really great job I'll try do work with this version until you got some time. :wink:

Off topic but do you have any road map of bepu ? ( the idea just come in my mind)

Norbo
Site Admin
Posts: 4884
Joined: Tue Jul 04, 2006 4:45 am

Re: new display method quite confusing

Post by Norbo » Wed Apr 23, 2008 12:46 am

There is a bit of an overall plan, yes- it is partially based on the remaining 'fundamentals' that are needed, and then other features which are going to be useful in our own future projects.

In terms of a basic outline, v0.6.0 is shaping up to be a solidifying of the 'deep' functionality. In the current plan, this entails joint enhancements and features and better behavior, as well as frameworks for making collision detection faster and 'feel' nicer.

After that, there will be most likely be a v0.7.0 which incorporates some extra 'neat' things (I'm looking at heightmap based water as an option for example, since it would not be extremely difficult to incorporate into the existing systems). This version will also take in any slack that I've neglected to add in v0.6.0. One feature that is going to be very handy for us that will likely be in v0.6.0 or v0.7.0 will be a method for keeping floating point precision high even at locations far from the 'true' origin of the space, and supporting segmenting the infinite space into large sub-areas (with seamless switching). The final goal for such a system would be a large-scale partitioning of jobs, which should have applications in distributed computing. This final goal may not be achieved in the first implementation, but I digress.

Once I feel I have satisfied as many 'loose ends' in the engine in terms of fundamentals that I can in v0.6.0 and v0.7.0, I will start work on v1.0.0. This will be a fairly sparse version in terms of total number of changes or additions, except for the one huge whale of extensive multicore support. I intentionally plan for this feature to be almost alone, because migrating the entire engine to use multicore is going to require a massive reorganization. Ideally, the result would be an arbitrarily scaling system that can be thrown any number of cores with near-linear increases in normal game situations. This will allow much greater Xbox360 performance, and excellent futureproofing for new manycore processors.

Chronologically speaking, v0.6.0 and v0.7.0 should be shorter in release intervals than v0.5.0, mostly because I will be able to invest quite a bit more time in development. Additionally, they will likely have less total changes. I'd like the v1.0.0 to be ready by the end of summer or fall, though forecasting that far out encounters many variables that I can't accurately account for.

After that release, I will look into more 'cool' physics; this includes soft bodies, destructibility, and dynamic fluids. Release dates for those features are almost impossible to predict at this point :)

Of course, the above leaves out many, many smaller features that will fit in between the large bits. I'm always trying to improve parts and speed things up.

User avatar
Zukarakox
Not a Site Admin
Posts: 426
Joined: Mon Jul 10, 2006 4:28 am
Contact:

Re: new display method quite confusing

Post by Zukarakox » Wed Apr 23, 2008 8:11 pm

Geez, just post your plan for global domination for anyone to read :(
i has multiple toes

sueds
Posts: 43
Joined: Tue Feb 05, 2008 10:40 am

Re: new display method quite confusing

Post by sueds » Wed Apr 23, 2008 8:30 pm

sounds nice ! I Can barely understand mechanics behind softbodies but destructible thing seems a way far away from understanding. Anyway everthing seems really cool you are going to compete with bulllet, newton and other physci package.

keep going.

Norbo
Site Admin
Posts: 4884
Joined: Tue Jul 04, 2006 4:45 am

Re: new display method quite confusing

Post by Norbo » Sat Apr 26, 2008 6:17 am

Would a premade .dll encompassing the Display system (mirroring the way it used to be), along with the regular source, make it more portable/easier to use for you?

I've included a wireframe renderstate toggle as well.

sueds
Posts: 43
Joined: Tue Feb 05, 2008 10:40 am

Re: new display method quite confusing

Post by sueds » Sat Apr 26, 2008 12:09 pm

this is great I was going to try to create one so you save me a lot of time !This is exactly what I was wishing ! thanks !

By the way I have a question. I've made a small level with a box falling onto the ground but the box seems a bit slow how can I do to accelerate the movement of the physics without changing the gravity ? There is something like the physics rate already ?

cheers and thanks for your good work !

Norbo
Site Admin
Posts: 4884
Joined: Tue Jul 04, 2006 4:45 am

Re: new display method quite confusing

Post by Norbo » Sat Apr 26, 2008 10:24 pm

Changing the Space.timeScale from 1 to some other number (2 for twice the speedup for example) would do the trick.

sueds
Posts: 43
Joined: Tue Feb 05, 2008 10:40 am

Re: new display method quite confusing

Post by sueds » Sat Apr 26, 2008 10:49 pm

I've just try it working ! :D

The only problem is the box don't sleep any more (still shaking) maybe there is another thing I need to change ?

cheers

Norbo
Site Admin
Posts: 4884
Joined: Tue Jul 04, 2006 4:45 am

Re: new display method quite confusing

Post by Norbo » Sat Apr 26, 2008 11:03 pm

Hmm, that's a bit strange- that could be caused by huge geometry, such as if it's sitting on a triangle that's 400x400 units. If the speed of the block is extremely fast it could be having trouble converging as well; you could update twice. This would double the simulation speed while keeping the exact same accuracy, at the cost of some performance. Basically, in your update method, just call Space.update twice with the same update rate. You could adjust the time scale or update rates from there to get it to the desired speed.

Norbo
Site Admin
Posts: 4884
Joined: Tue Jul 04, 2006 4:45 am

Re: new display method quite confusing

Post by Norbo » Sun Apr 27, 2008 10:41 pm

Here's two display .dll's, for windows and xbox360. I'll be putting these on the website along with v0.5.1 later today probably.
Attachments
BEPUphysicsDemosDisplay Xbox360.zip
(14.49 KiB) Downloaded 171 times
BEPUphysicsDemosDisplay.zip
(14.57 KiB) Downloaded 234 times

sueds
Posts: 43
Joined: Tue Feb 05, 2008 10:40 am

Re: new display method quite confusing

Post by sueds » Sun Apr 27, 2008 11:24 pm

hello ! thanks you again ! this is great !

sueds
Posts: 43
Joined: Tue Feb 05, 2008 10:40 am

Re: new display method quite confusing

Post by sueds » Mon Apr 28, 2008 2:55 am

I got a problem with the display system. I'm not able to make it work, can you explain what we need to use it properly ? Do I need to transform it as a regular mesh ?


cheers

Post Reply