Framework Request
by John Kanalakis · in Torque X 2D · 12/08/2007 (5:51 pm) · 4 replies
The 2D and 3D Frameworks are inconsistent from each other and will be confusing to new programmers. You add a T2DSceneObject to a 2D scene, so you should also have a T3DSceneObject to add to a 3D scene. Instead, it seems like you have a completely different path... create a generic TorqueObject, then add a T3DDTSRenderComponent and a T3DSceneComponent. As much as I like the component separation, I do think there should be a single 3D scene renderable object. In short, instead of this...
You should have this...
Now, of course I can code that myself, but I think it would be great for GG to add (even a simple wrapper class like GarageGames.Torque.T3D.T3DSceneObject ) into the framework - simply for consistency and easier learning when developers move from 2D to 3D.
Thank you,
John K.
TorqueObject objPlayer = new TorqueObject(); T3DTSRenderComponent componentRender = new T3DTSRenderComponent(); componentRender.ShapeName = @"data\shapes\sphere.dts"; T3DSceneComponent componentScene = new T3DSceneComponent(); componentScene.Position = new Microsoft.Xna.Framework.Vector3(1024, 1024, 300); componentScene.RenderObjectBounds = true; objPlayer.Components.AddComponent(componentRender); objPlayer.Components.AddComponent(componentScene); TorqueObjectDatabase.Instance.Register(objPlayer);
You should have this...
T3DSceneObject objPlayer = new T3DSceneObject(); objPlayer.ShapeName = @"data\shapes\sphere.dts"; objPlayer.Position = new Microsoft.Xna.Framework.Vector3(1024, 1024, 300); objPlayer.RenderObjectBounds = true; TorqueObjectDatabase.Instance.Register(objPlayer);
Now, of course I can code that myself, but I think it would be great for GG to add (even a simple wrapper class like GarageGames.Torque.T3D.T3DSceneObject ) into the framework - simply for consistency and easier learning when developers move from 2D to 3D.
Thank you,
John K.
About the author
John Kanalakis is the owner of EnvyGames, an independent game development studio in Silicon Valley that produces games and tools for Xbox 360, Windows, and the Web.
#2
The reason for having even how an object renders managed by a component has a couple of subtle, but strong benefits:
--as a component, it can be changed at run time. Think about things like having the ability to do CPU load based performance monitoring, and, for example, dropping to a lower powered lighting model if the target computer isn't keeping up with the high powered one.
--as a component, it can be replaced incredibly easily and (mostly at least in theory!) smoothly. Again, think outside the box--what if you have this really amazing fluid render library (hypothetical) written by a third party, but it is a pretty extensive system. You don't want to have to directly integrate it with your main code, or TorqueX--all you really need to do is to write a new component that interfaces your library with TorqueX via your object's render component.
In general, the entire idea of components pushed to the theoretical edge is to remove connotations, and even direct requirements that lead to Kzoink's statement:
The implication here is that rendering is part of an engine's low-level code. Where use of components at this level is going is to remove that assumption -- why should your engine limit or control absolutely how things like rendering occur? Much better to let you have the flexibility to make those decisions yourselves--and make the decision as late as possible : run time.
12/09/2007 (10:39 am)
Part of the difference you see between the two is due to the transitory nature of where TorqueX started ( very similar to Torque Game Builder), and where it's finishing up (very similar to where Torque 2 is going).The reason for having even how an object renders managed by a component has a couple of subtle, but strong benefits:
--as a component, it can be changed at run time. Think about things like having the ability to do CPU load based performance monitoring, and, for example, dropping to a lower powered lighting model if the target computer isn't keeping up with the high powered one.
--as a component, it can be replaced incredibly easily and (mostly at least in theory!) smoothly. Again, think outside the box--what if you have this really amazing fluid render library (hypothetical) written by a third party, but it is a pretty extensive system. You don't want to have to directly integrate it with your main code, or TorqueX--all you really need to do is to write a new component that interfaces your library with TorqueX via your object's render component.
In general, the entire idea of components pushed to the theoretical edge is to remove connotations, and even direct requirements that lead to Kzoink's statement:
Quote:
It does seem strange that the engine's low-level code would be put into a component like that.
The implication here is that rendering is part of an engine's low-level code. Where use of components at this level is going is to remove that assumption -- why should your engine limit or control absolutely how things like rendering occur? Much better to let you have the flexibility to make those decisions yourselves--and make the decision as late as possible : run time.
#3
I would suggest adding a new class called T3DSceneObject which is a simple wrapper that includes a T3DTSRenderComponent and T3DSceneComponent, just like the T2DSceneObject which wraps T2DPhysicsComponent, T2DCollisionComponent, and T2DWorldLimitComponent. You can include this class just for learning sake, then let developers drop this class for the advanced flexibilty you mentioned. This simple class would be a great way to hide the evolution of Torque X code and ease the 3D learning curve.
John K.
12/09/2007 (1:26 pm)
I can see the benefit of having the scene presence and shape render functionality as components. My comment goes more to the fundamental paradigm shift between the 2D and 3D frameworks - especially in the Educational field. I think that someone starting out with the 2D code and just learning about components will have a hard time advancing to the 3D code. I would suggest adding a new class called T3DSceneObject which is a simple wrapper that includes a T3DTSRenderComponent and T3DSceneComponent, just like the T2DSceneObject which wraps T2DPhysicsComponent, T2DCollisionComponent, and T2DWorldLimitComponent. You can include this class just for learning sake, then let developers drop this class for the advanced flexibilty you mentioned. This simple class would be a great way to hide the evolution of Torque X code and ease the 3D learning curve.
John K.
Torque Owner Kzoink