Thinking out loud - Lets focus on Accessibility, Performance and Multi-platform for Torque 3D

#21 That sounds cool too, though. That way you'd have the occlusion result faster. With occlusion queries you either have to wait for the GPU (which lowers fps) or use the result the next frame. Always a trade off.. :-(

#22 Since the theme of this thread is thinking out loud, I've had a crazy idea floating around in my head ever since I started changing TSMesh to add cloth. What if we created two base classes to rule them all and a plugin system to add optional functionality to each of them. I'm thinking: Objects and Actors. Objects being anything placed in the world with the world editor, actors being essentially what shapebase/player is now (spawned, networked), only with as much optional functionality stripped as possible and moved into plugins/extensions/whatever you want to call them.

How would this be accomplished? Honestly, I'm not entirely sure. I've been tossing the idea for awhile now. This is what's held me back from creating a prototype to demo, I'm not sure entirely sure the best way to approach it, or if it's even a good idea. I was holding off making a post about it before I had something to show the idea in action. But since we're thinking out loud here's what I dream of for plugins/extensions/whatever:

- The ability to tap into any of the classes base functions (initPersistFields, processTick, etc) without disrupting other plugins or the base class itself.
- Menu options are automatically added to the class for use in the world editor inspector, so adding a plugin will immediately expose it's functions to existing objects without script or mission file alterations.
- A plugin can be enabled/disabled on a per-object basis and will hide all of it's menu options when disabled to reduce clutter in the object inspector. No calls will be made to the plugin on a per-frame/tick basis so lots of plugins will not slow down large amounts of objects that don't use them.
- Completely removing a plugin from a project removes all the functionality without breaking the objects themselves.

So, for instance take physics. Instead of having physics objects separate from TSStatic's, an object would be an object. So, I'd go through my mesh list and add in a mesh of my choice. In the inspector I click off "Physics" and it exposes all the physics related properties while simultaneously enabling the physics plugin within that object. So now, when processTick() is called again, the Physics plugin gets a call with a reference to that object that's calling it, so it can perform anything it has to for that specific object.

A simpler example: lets say I make a "bounce" extension for some reason. It adds the option "bounce" to all the objects. You add the extension, then recompile. You click any object in your existing level, check off bounce in the inspector, and now the object is bouncing up and down by using it's processTick to change it's position.

Obviously there's 100 different questions raised from this idea. Performance for one. Where are datablocks in all this? etc. Questions I haven't come up with answers for yet. I figured I'd toss this out there in the spirit of the thread. Thoughts? Comments? Am I crazy?

#23

Quote:
Since the theme of this thread is thinking out loud, I've had a crazy idea floating around in my head ever since I started changing TSMesh to add cloth. What if we created two base classes to rule them all and a plugin system to add optional functionality to each of them. I'm thinking: Objects and Actors. Objects being anything placed in the world with the world editor, actors being essentially what shapebase/player is now (spawned, networked), only with as much optional functionality stripped as possible and moved into plugins/extensions/whatever you want to call them.

I gather that's at least one of the intents behind www.garagegames.com/community/blogs/view/22555 Or at least that's the approach I'd likely take, m'self.

#24 Yeah, I've read about it. His system seems far more complex, which means it's possibly better or I'm completely underestimating what I'm proposing.

I guess the key difference is my idea piggybacks on top of the existing TSStatic and ShapeBase functionality while pulling out a few features (pulling physics from shapebase, possibly a few other things) and adding room for new features to be added easily. I don't think it would take very long to implement for testing, and if it was approached carefully legacy support for ShapeBase and TSStatic could exist as we could just duplicate the classes and add extension support.

It looks like Jeff's completely guts the system and reworks everything into a behavior based system. Which may be a better choice, I'm not sure. Again, just thinking out loud :P

#25 Your system and Jeff's are equivalent as far as I can tell from your description, but I think Jeff's approach of gutting everything is the correct way to go about it. Otherwise you only get half the benefit, and you're still stuck with a bunch of cruft from the current class hierarchy - for example, StaticShape and TSStatic being separate but both basically doing the same thing in terms of shape rendering and collision.

It's more work to rewrite stuff like rendering and collision primitives, but it will result in real benefits.

#26 True enough. I'll place my bets on Jeff then.

#27 @Nils "- Allow NULL as the lowest possible detail, instead of imposters"

If that would work the way I imagine it might it would be extremely useful.

#28 I'd like to vote for the performance enhancements because I think, with these, the engine code would become a little more intelligent and a little more clean.

I have always used open source projects, but it is difficult to choose Torque3D over something like Unity when the community is comparatively small and you are starting at a disadvantage. I've loaded the same scene in Torque and Unity. With deferred lighting I get around 10 FPS in Torque and 15 in Unity and Unity looks "better." So I think having an open engine that can outperform Unity will drive traffic to Torque and intern grow the community and the number of those who contribute to its development.

Getting/finishing the OpenGL implementation is also very important so that we can target other platforms.

On a personal note, I would be completely open to helping with these advancements, but I'm in a position where I'd be risking my first indie project and at the moment efforts are hard to find (isolated posts on these forums) and its difficult to have confidence in the engine given its rocky past.