Torque 3D Community Edition Discussion Thread

#61 I like what Jeff was saying. To add the gameplay elements to script. That would make the engine a little more easier, plus someone wouldn't need to know C++ to achieve a desired effect. Some of the suggested features or improvement I've suggested, pretty much come from different resources. Maybe with a little work they could be made features. For example, the Advanced Camera. That could actually work for a camera system, of course make it easily customizable.
Some of the other things were things I'll been thinking on for a long time and I felt T3D needed, or could really help the engine out.

#62 Frank: good idea. Though I do think there should be a relatively intensive test map that would act as a performance benchmark. The breakabilty tests you mention above would serve a different, but important purpose, and having a workhorse mission for consistent performance benchmarking on a 'real' game scene would be a good idea as well.

I may be able to look into whipping up a test mission with a static camera fly-through with the attached content if we are indeed inclined to go that route.

#63 @Jeff,
If you create a performance benchmark with a fly through I would make it so you can record FPS, network ping (might be hard), and any other metrics that would considered performance related. This data would be recorded to a database for each fly through at specific points along the path. That way you can see if portions of the simulation are getting improvements you might not be able to see with a spot check.

@All,
I am working on #25. So far I am partitioning out all the variables used in a call to exec back into the CodeBlock class. This allow each opcode to be a function and have access to state information. Once I do that I will break out all the opcodes into separate functions void opname(void). Then I will build an array of the opcodes that line up with the opcode enums. This will be used to index the next opcode and take advantage of tail call optimization. I am doing this against stock 1.2.

#64 That'd be pretty cool.

I'll see what I can whip together in the next week or so.
Is there anything in particular you guys think I should focus on/showcase elements-wise?

Oh! That reminds me. I actually wrote a script-side profiler too. I need to give it a few tweaks, but functionally it's fairly similar to the engine profiler function. You define a start and end, and it tracks(via a small addition to the engine) how long it takes to go between. Tracks number of calls, average time, total time, etc Then spits it out into a text file for viewing pleasure.

So if you're building a 'performance track suite', it'd make sense to have it keep tabs on that and engine profiles as well.
I bet you could track that out to a DB(like you said) and use the built in graph GUIs to see it present the demo scene's performance out over a timeline so you can see what parts are the most intensive between FPS, network ping, engine and script profilers.
That sound worth pursuing?

#65 @Jeff,
High poly count objects in one area, high amounts of vegetation objects in another area, high amounts of physics interaction objects in another area, high amount of AI in another area, etc.

Then as needed add areas that mix these elements for specific cases. Maybe even separate missions that are automatically cycled through.

#66 I'm thinking we could have a mission for each that are cycled, and then a master fly-through that hits all elements in one go(This would help narrow down stuff like scoping performance for AI if they're not in view, etc, etc).

#67 A random note: I reckon this would be a great enhancement!

#68 I think the CE is a great idea. And I will do what I can.

I think the focus of the CE and GG in general should be to make using T3D easy enough for people to really start to release games.

Instead of using T3D and release a game people are making fantastic mods using the FPS games out there. Why aren't they doing the same with T3D? Because it doesn't have the resources and the simple features that are needed to get straight in the game making.

Like in another thread Ron Kapaun, mentions the lack of ease in animating speech on models. We don't even have an out of the box rag dolls. And many more things which are mainstay in todays games, and this catchup that is needed to be done by developers is holding back people from releasing great games in my opinion.

CE I think should be about getting those required features in to the engine, we're the end-users of T3D and we know what the lacking features are.

As mentioned earlier in the thread, about OpenGL. I think OpenGL is the better option instead of Direct3D 11 due to the simple fact OpenGL doesn't drastically change between versions so its easier to upgrade and use new features and also to fallback. Plus it allows cross platform, instead of DirectX 11 on Windows and OpenGL for Linux/MacOS it's just OpenGL across the board and with fallback for the version available for the different OS.

#69 In regards to Resource or features requests and other enhancements: so long as it doesn't interfere with or duplicate existing functionality, decrease performance, or increase network traffic (which is already somewhat bloated in stock), anyone is welcome to take on the task to integrate them - especially if they enhance them in turn.

The only real standing rule that we have is "don't break it" and "don't dirty the code". Small "atomic" commits are easily reverted in case of problems. At some point I feel that we should have a separate branch for more volatile changes and long-range goals -- but that is something that will be in Alfio's hands since it is his server and his bandwidth that he is donating.

#70 no request or suggestion.just a thought.personally i do not think it is necessary now.but for future support on cross platform.

cross platform shading language:
http://en.wikipedia.org/wiki/Cg_(programming_language)

here is the compiler:
http://developer.nvidia.com/cg-toolkit


may be unity use cg shader for it's iphone and other platform.not sure.

#71 @Edward, I agree with the OpenGL but garagegames already stated that it not in the license to have an OpenGL version of T3D. So I guess for now we have to put it off. Unless garagegames gives the go head.
Everything else I agree with and been ask for some of the features for years. I just now started getting to a point were I feel somewhat safe to contract shader developers and programmers for work. If we can get more unified features and tools, I believe Torque3D would be putting out AAA title games on consoles and etc.

#72 All, not for sure if anybody knows but Yuri over at logicking is planning on stopping development of GMK and guidebot. It doesn't have any effect on the community members that aren't license holder but to the one that are and part of the T3D 1.2 CEV. Maybe we should do a push to get at least some of those features apart of the CEV?

#73 To be clear, we never said anything about not allowing OpenGL. We just noted that porting to console platforms as noted by a couple people, would require special licensing agreements since that is in the EULA. Porting GFX2 to OpenGL is not an issue. Porting to platforms outlined in the EULA was.

#74 Also, on Unity and CL. I believe they use an abstraction layer and bridge. They had a github project on it, but I cannot recall it now. Pretty nifty project.

#75 -- Removed duplicate post from using my phone --

#76 Fixing the audio to work for "music" and "interface" channels on bootup would be a good addition. Currently ALL audio is initialized only when a server is created.

edit: I made out a ticket for this.

#77 I'd like to see an editor or script system for defining animation actions for the player. Right now it's kind of opaque in terms of being able to change how player movement works without getting into the C++ for it.

#78 Well, like I'd mentioned prior, there's the Script-defined animations resource, and then you'd set up a script-defined stances system based off similar rules. This way it can all be defined and controlled in script. This is what I've done for the game I'm working on.

That said, I can't dedicated huge amounts of time to this just yet, as I'm crunching on my current project to get it done as quickly as possible. That said, when that's more close to completion, I'd always intended on polishing up and finishing several tools and utilities I've got cluttering my HD. Several of these would be perfect for CE. A few of note is an Updated Conxex Shape tool that lets you apply textures on a per-surface basis, as well as per surface UV offset and scaling. Another is a skeleton abstraction that works with any Shapebase-derived class. It lets you control the bones directly(I'm planning on adding script hooks, and custom cross-blends for almost infinite animations) as well as IK and jigglebones. Rag dolls should be pretty doable on this system as well.
The last biggie would be a Visual Node script tool. So you could do script visually in the editor itself. I'd planned on expanding that to cover game scripts, materials and shaders via different 'tabs' on the editor.

All of those are in various levels of completion(the convex tool is almost final, actually, the skeleton is the second most complete), so when I get some additional time, I can start polishing those up and begin cramming them into the CE.
Anyone have any requests or suggestions pertaining to any of those? I'd be all ears for things you guys think I should keep an eye out for when polishing them for wider usage. I'd estimate I can start working on those end of the month-ish, no huge development delays withstanding.

(Look at what happens when you have feature creep for a few years :P )

#79 @Jeff, Nice I can't wait to see them integrated. Some of those tool are tool T3D could've used awhile ago! Now if we can get an cutscene editor and an AI editor we would really be in business.

#80 @Kory
What are you thinking of when you think 'AI Editor'?
Because if you mean an easy-to-setup sort of state machine, that may be an extension that could be setup in the node editor. You'd just need to set the hooks up into the player class, probably a dedicated 'brain' that you could then set up state trees via the visual editor(which would make things MUCH easier to organize, behavior-wise) To tie to a specific 'brain' type.
Or are you thinking a more in-depth kind of parametrized editor of sorts?