Torque 3D 'toys' or demos

#21 I don't have a have a lot of spare time these days dan but i'll definitely help out where i can with this, i think it's something that will definitely help a lot of people. I think t3d-bones is the perfect platform for it ( the editor part is the trickiest i think ). Just let me what i can do to help.

#22 Perhaps the triggers/door one could also have buttons in the level that you can press with the E key or whatever, also the vehicles one should have more vehicles than just the cheetah.

#23 Yeah. For the doors one, I'd say you could have:

Proximity doors(trigger around the door, when the player gets close, ie hits the trigger, door opens)

Direct interaction, you look at the door and hit the interact key, door opens

And Indrect interaction. You go to a switch on a wall, hit interact on it, and door opens.

I think that'd cover your various door methods.

#24 Here at last something that I wanted to hear for a long time here.
it's a great idea that would have minimal unnecessary things in every technical demonstration level scene, there should be many, but tiny, each one considered only spetsefichesky thing, and nothing else except the functions that are needed for that! it will give a minimum of investment of time for consideration and maximum concentration experience and understanding of the lessons, demonstrations!
PS Daniel a great initiative! I rely very'll see that it will be implemented nearest future, and in the new release ...

#25 Terrain and weather?

@Daniel Have you looked at the demo levels for TGE 1.4.2 and 1.5.2? It might give you some additional ideas. Also, I believe it answers questions that newcomers would like to know.


I like Unreal's, "muesum style", for demos. Example; I want to see what torque can do with with particles. I download the particles demo. I walk around and interact with each particle "exhibit". I stop by the fire exhibit and aim my crosshairs at different buttons. The buttons change the fire colors and intensity.

#26 @Britt

That sort of main menu is something me and Dan where discussing last night.

Having a central examples executable, and it then launches each sub-example would definitely be the ideal. Keeps the parts separate and small, but easy to launch and test.

As for the museum style levels, I agree. The particles exmaple mission could be structured like that, as could my above door example.

If i remember right, the Source SDK had some levels set up like that. One had several AI interactive/scripting behaviors lined up so you could test them quickly, like having an AI walk to a target, interact with something, etc.

For subsets of the same example, a museum style level would be pretty awesome.

#27 On the other hand, it increases the amount of stuff in each scene when you're digging through the code trying to work it out. Though it it's coded well, it should be fine. Does UE have a literal museum environment you walk around in? I was imagining most scenes being little more than a groundplane and a sun, plus the object of interest :P.

Britt: Terrain and weather both good ideas. Having bespoke GUI controls for each example is also definitely something I want to do. It will probably be an actual GUI though, not ingame buttons. I do remember the TGE demos, but they were a little more like templates, which are also something that should be done.

Timmy: I guess what I'll do is put together a framework based on t3d-bones, and then solicit new examples in the form of pull requests. Initially, I suppose, the editors won't be there. Refactoring them to support nontraditional templates will take a few weeks at least, and I want to get this going faster than that. So to start with, you'll have to script everything manually :P.

Question: obviously some examples are all about art. Do we stick .blend files in the repo? What about the generated .dae files? I think this will end up being inevitable. I think making everything in Blender is a desirable goal, because people will want to see how the source art is set up.

EDIT: something I do want to insist on for this structure is that every example be completely self-contained. No art/ directory, no terrains/ directory, everything goes in the folder for its own example. I still believe this will make it easier for people to poke around and explore. This also means minimal sharing of assets between examples. Good idea or bad?

#28 @Jeff

Glad that sort of menu is being discussed. I like the idea of walking around and discovering new things.

#29 @Daniel

I should clarify, i don't mean the starter.folders. I was refering to the demo that shows how; lods work, image/object mounting, mirrors, lighting, etc,.

I agree with the projects being self contained.

I vote for .blend and .dae. Maybe fbx?

#30 @Dan

When I'm imagining a museum level, I mean in a loose, metaphorical sense. Not necessarily that we have a huge building environment.

Just having the ground plane with a few Convex Shapes as podiums to emphasize the particle effects or whatnot would likely be sufficient for most of those kinds of examples.

As for the structure, I agree on minimal/no sharing of assets. It'll bloat the examples build some, but it also will make each example a lot cleaner and self contained.

And yeah, .blend and .dae is probably sufficient when it comes to source art.

#31

Quote:
Does UE have a literal museum environment you walk around in?

Pretty much - It's a hallway divided into sections with three to five related demos in each section. There are at least two of those, one for scripted events and interactions (using Blueprints) and one that has several particle effects and ambient stuff. Plus they made the "Elemental" demo - a cave and mountain scene with all sorts of fire, water, ice, and wind special effects. I should package them up like games so you guys can walk through them and see.

#32 Britt: the engine can't read FBX so it doesn't really seem useful. .blend so that users have the source, .dae so the engine can read it. Though DAE is a generated file, we probably don't want users to have to generate DAEs before they can run the example.

On the other hand, we could pre-generate DAE files before producing downloads. If someone wants to clone the repo directly maybe they shouldn't mind exporting the DAEs. We could probably provide a batch script to do it, as well.

Ah, right, I remember the demo you're talking about now. It had dancing Kork. I did like that, though again I think what I want to propose here isn't quite like that. We should probably do something like that at some point, as well.

I guess, to be clear, these examples shouldn't be eye candy that convince people to use the engine. They should be educational, and documentary.

Maybe there should also be some 'base' assets in a shared directory. Like a cube, grid textures, etc. Maybe a podium :P.

#33 Probably best to keep .blend files in a separate repo for research purposes. Last I checked, blender still had a few issues with importing daes with bones.


Edit: Actually, looks like blender is now properly re-importing the soldier's dae bones, instead of treating them as empties. YEEEEEEESsssss.

#34 I only mention fbx because of 3ds max and Maya. But as long collada imports, it's all good.

Screen fom the Unreal Content Samples...

#35 Oh gosh. Well if someone wants to make that then go ahead...

#36 Daniel, I think you have taken a very correct course of thinking! maybe I just give my vision of how I imagine it to be so is put together and work inside, I would see the following directory structure inside "project" directory ...

"Project name"
/ - "Global (public) resources"
/ - "Scenes"
/ - / - "Name Scene # 1"
/ - / - / - "Local (Exclusive) Resources"
/ - / - "Name scene # 2"
/ - / - / - "Local (Exclusive) Resources"
/ - / - "Name Scene # N"
/ - / - / - "Local (Exclusive) Resources"

the difference between local and global, I thought is clear and without explanation ...

#37 Actually, to bring up the whole lightmap/tonemap thing ... I've never quite understood if theLevelInfo's "useAdvancedLightmapping" setting and theSun/lights multiple "AdvancedLightmapping Settings" work as expected ... or even not so sure how they are supposed to work ... :S

Having lights with set to use advanced lightmapping looked ruddy awful (huge white spec which has no lightmap/tonemap info) the last time I used way back in the days of Catchick et al.

#38 Olexiy, that's exactly what I'm thinking.

There should also be some GUI examples (for which we don't necessarily need a 3D scene) - for example, tab pages, or drag and drop. Also maybe a demo GUI that explains horizSizing and vertSizing!

#39 @Steve Acaster

that's exactly the point! why have a feature if it is broken or don't have a clue on how to properly utilize this?

this is a big let down for artist who likes to implement lightmapping in their scene but no idea how it works.

#40 The more I think about this the more I kind of just want to make a little area in the wiki for documentation like this. I've been thinking about how all the current script code we have stops us from innovating (i.e. moving everything to TAML) because of the need to keep all that code updated. Aside from the amount of work it would be to code and maintain these examples, it'd just mean more code that would give us more inertia.

On the other hand, it seems very important we have examples that are easily accessible for people. So I'm torn. I also want to just not write examples, and instead focus on doing template/demo stuff like the 7DFPS stuff I was working on.