Version Roadmap
Re: Version Roadmap
Updated the roadmap to reflect v0.14.0's release.
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
0.14 is quite a bit faster on my old quad core
Great work norbo.
I assume 0.15 will be split up further? Whats coming first?
Bepu just keeps getting better and better at an amazing rate.
Great work norbo.
I assume 0.15 will be split up further? Whats coming first?
Bepu just keeps getting better and better at an amazing rate.
Re: Version Roadmap
The engine is going to have to undergo a significant architecture revision to start the process. The goal of the new architecture will be to make everything extremely modular, with clear cut responsibilities assigned to newly visible stages in the pipeline.
When you open up the space's intellisense, I'd like these different stages to be obvious and accessible. I'd like to also break up the slightly dated simulationSettings into each individual stage object, since the settings will depend on which system is being used at the time.
Once that's done, individual chunks will start getting rewritten to fit into the new framework. Terrain/StaticTriangleGroup are high on the list at this point. Once those are done and the other ones have been adapted to the framework, I'd consider doing another release. If it doesn't take too long to get to that point, I might rewrite the GJK/MPR and continuous collision detection systems before releasing the first iteration too.
I'm looking forward to the rewrite since the box-box revision showed that there are some definite speed/robustness gains to be had that will benefit all three platforms significantly.
When you open up the space's intellisense, I'd like these different stages to be obvious and accessible. I'd like to also break up the slightly dated simulationSettings into each individual stage object, since the settings will depend on which system is being used at the time.
Once that's done, individual chunks will start getting rewritten to fit into the new framework. Terrain/StaticTriangleGroup are high on the list at this point. Once those are done and the other ones have been adapted to the framework, I'd consider doing another release. If it doesn't take too long to get to that point, I might rewrite the GJK/MPR and continuous collision detection systems before releasing the first iteration too.
I'm looking forward to the rewrite since the box-box revision showed that there are some definite speed/robustness gains to be had that will benefit all three platforms significantly.
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
Is this the re-write that will make most object types first class objects in the broadphase etc?
Yer the box vs box helped performance and robustness of heavy box collisons
What kind of improvments would the new CCD bring?
Eather way its going great
Yer the box vs box helped performance and robustness of heavy box collisons
What kind of improvments would the new CCD bring?
Eather way its going great
Re: Version Roadmap
Yes.Is this the re-write that will make most object types first class objects in the broadphase etc?
The current CCD is very 'strict,' in that it tries to prevent any penetration at all (until such a goal becomes impossible). A side effect of this is over-conservative movement when there's not really a danger of escaping the map or anything. The extra strictness can be valuable sometimes, but in many cases, all you want is to keep things from flying through walls without caring too much if a bit of penetration happens now and again.What kind of improvments would the new CCD bring?
The new CCD system will basically be a bit looser, allowing for greater speed and sometimes more stable approaches. The concept of predictive contacts could help too, so that there's always an extra constraint preventing further penetration once it's detected, even if the normal contact manifold is empty. This would make it much harder to pull a box through the ground by applying a constant heavy force.
The existing strict versions of CCD will remain and will get general robustness/speed improvements from the rewrite process.
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
Those improvments to ccd sound great I hope they turn out how you hope.
Cool and thanks for the update.
Cool and thanks for the update.
Re: Version Roadmap
Creating the .NETizer application is taking longer than I'd like. At this point, it could take a few weeks to get it where it needs to be to handle arbitrary projects well. I'm considering dropping that in favor of getting the release out much faster (a matter of days instead of weeks). This would let me get to the high priority collision system rewrite work faster.
The downside to not having the application, of course, is that everyone would have to upgrade manually. That's definitely going to be a pain.
If there's enough interest in it, I'll work on the .NETizer application some more (just let me know), but otherwise I am going to push for working on the collision system sooner.
The downside to not having the application, of course, is that everyone would have to upgrade manually. That's definitely going to be a pain.
If there's enough interest in it, I'll work on the .NETizer application some more (just let me know), but otherwise I am going to push for working on the collision system sooner.
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
I think that it would be much better to just go onto the new engine stuff and let people upgrade themselves.
The collision system improvements should be worth it.
I think the manual upgrade will be fine.
Has it been decided what v0.15.0 will be split up into or does everything in it rely on everything else?
Anyway just wanted to know whats going on, have a great day
The collision system improvements should be worth it.
I think the manual upgrade will be fine.
Has it been decided what v0.15.0 will be split up into or does everything in it rely on everything else?
Anyway just wanted to know whats going on, have a great day
Re: Version Roadmap
The stuff that's going to be in v0.15.0 is still a little vague. I need to do some more designing after v0.14.1 is out to see how things best fit together, then I can start filling in the gaps with the highest priority features.
I'd expect the 'first version' of v0.15.0 to have a significant portion or all of the modularization completed, with broadphase, narrow phase, solver, position updater, etc. all split into their own subsystems. The concept of abstract collision shapes and the 'first class broad phase citizen' thing should make it in, as well.
The revised Terrain/StaticTriangleGroup would go along with that. I'd also like to finally deal with the buffered property confusion.
Beyond that, it'll basically be up to what fits and how long it will take.
As for v0.14.1, it's very close to being done. I'm testing it by incorporating it into and updating all the documentation demos, which is almost done.
I'd expect the 'first version' of v0.15.0 to have a significant portion or all of the modularization completed, with broadphase, narrow phase, solver, position updater, etc. all split into their own subsystems. The concept of abstract collision shapes and the 'first class broad phase citizen' thing should make it in, as well.
The revised Terrain/StaticTriangleGroup would go along with that. I'd also like to finally deal with the buffered property confusion.
Beyond that, it'll basically be up to what fits and how long it will take.
As for v0.14.1, it's very close to being done. I'm testing it by incorporating it into and updating all the documentation demos, which is almost done.
Re: Version Roadmap
Updated the roadmap to reflect v0.14.1's release (I'm glad that's over), and clarified v0.15.0 a bit (still hasn't been split yet).
Re: Version Roadmap
Quick update:
The design for v0.15.0 has been completed, and its infrastructure implemented. The 'meat' of the old systems is now being pulled into the new design. Once the compatible pieces are reincorporated, the work will begin on the reimplementing features like triangle meshes to reach feature parity with previous versions before releasing. The subsequent version ("v0.16.0" for now) will include most of the extensions that go beyond what v0.14.X and prior could support.
It's still a little early to guess a release date, but progress is being made.
The design for v0.15.0 has been completed, and its infrastructure implemented. The 'meat' of the old systems is now being pulled into the new design. Once the compatible pieces are reincorporated, the work will begin on the reimplementing features like triangle meshes to reach feature parity with previous versions before releasing. The subsequent version ("v0.16.0" for now) will include most of the extensions that go beyond what v0.14.X and prior could support.
It's still a little early to guess a release date, but progress is being made.
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
This is great to hear
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
Hey norbo i was just wondering when the .15 could maybe be out? any chance before the 9th of november?
Any idea on what kind of performance or accuracy differences we might see?
As our phone game is very physics heavy as you know so any benifits would be great.
Any idea on what kind of performance or accuracy differences we might see?
As our phone game is very physics heavy as you know so any benifits would be great.
Re: Version Roadmap
I can't say for sure either way on the date; November 9th might be cutting it a little close. Unfortunately I still don't have any better guess on the performance/robustness since it isn't yet in a runnable state. It's getting closer, though
If I were you, I'd operate on the assumption that v0.15.0 won't be available in time, just in case.
If I were you, I'd operate on the assumption that v0.15.0 won't be available in time, just in case.
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
Ahh ok i was just wondering as we are having a few accuracy issues in the game.
But yer we are assumeing that it won't be, it would be nice but yer can probably just increase the accuracy or time stepping so yer.
But yer we are assumeing that it won't be, it would be nice but yer can probably just increase the accuracy or time stepping so yer.