-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BulletEngine #579
base: master
Are you sure you want to change the base?
BulletEngine #579
Conversation
…tanced or not; WorldElementBuilder::build() -> buildWorldObject(); WorldElementBuilder::buildWorldObject() -> buildOther; .ini type for mere WorldObjects is not other
…ancedBulletPrototype
… into bulletengine
voxelcluster=pulselaser_bullet.csv | ||
lifetime=1 | ||
speed=500.0 | ||
spinning=0.0 | ||
scale=0.4 | ||
emissiveness=0.4 | ||
emissiveness=40 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
afaik emissiveness should be 0.0 - 1.0, has something changed?
generally looking good. couldn't enjoy the performance because I'm on laptop on battery |
class WorldObjectComponents; | ||
|
||
/** | ||
* Sets up WorldObject by the settinsg provided by properties | ||
*/ | ||
class WorldObjectBuilder { | ||
class WorldElementBuilder { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure this rename is good. I thing we're going to run in a name conflict here, because a WorldElement - as far as I understood - will be anything that's part of the world, including scripts, triggers, (internal)engines etc.
This builder (which actually is a factory or something as we found out^^) can only build these voxelbased things. Maybe another abstract class in this hierarchy is needed that is an "Object in a world" which consists of voxels and can be drawn or something.... what a worldobject used to be
class WorldObjectComponents; | ||
|
||
/** | ||
* Sets up WorldObject by the settings provided by properties | ||
*/ | ||
class WorldObjectBuilder { | ||
class WorldElementBuilder { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(repost)
Not sure this rename is good. I thing we're going to run in a name conflict here, because a WorldElement - as far as I understood - will be anything that's part of the world, including scripts, triggers, (internal)engines etc.
This builder (which actually is a factory or something as we found out^^) can only build these voxelbased things. Maybe another abstract class in this hierarchy is needed that is an "Object in a world" which consists of voxels and can be drawn or something.... what a worldobject used to be
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I consent, but can't really think of a a good name for a base class of InstancedBullet AND WorldObject... VoxelObject maybe... ideas?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Voxelobject doesn't sound too bad. Maybe - since this is all voxels - you can even drop the voxels and have an ObjectBuilder or ObjectFactory, because objects in our World are things that are spawned, moved, deleted and have a physical representation (position) in the world
Beside the naming of the WorldElementBuilder, anything else? |
I agree with the renaming, voxelobject sounds good. Runs smooth on my machine, code looks fine after renaming. |
Did the renaming ;) |
weren't we about to de-singletonize the world to allow sectors? because there is an awful lot of |
I don't think the de-singletonizing was for this PR. I have a pretty complete branch (that misses some other things) for sectors where World::instance() is gone, though |
is there a PR for that? If both should be merged... In order to not have the trouble when merging, maybe this feature should already be built without needing that lateron. Just a suggestion |
I made this mergeable again and looked over the code once more. I would probably solve it more generically today, but I think it is fine as it is. What do you think, one more shipit? |
Depends on #563 #568
Fixes #414
Code still needs cleanup and doc, maybe Line::intersects() can be optimised, but here it is: the BulletEngine
Please test it and report back. Expect significant improvements in the F2 battle, but there are still perfproblems with splitdetection and in VoxelRenderData::updateBuffer() (when using the homebase)