Artist and level designers
by Paul Yoskowitz · in Torque 3D Professional · 11/03/2014 (4:32 am) · 141 replies
Where do you feel that T3D is falling down as far as things for the artist and level designers?
This isn't about the latest DX/OGL or anything like that. What tools are missing compared to other engines out there right now that you feel would breathe new life into T3D-MIT and make development easier for you?
This is the list so far of issues or things that need added:
*Interior/structure designer like Constructor
*Prefab object that combines models and scripts
*Improve forest editor
*Beefing up the sketch tool
*Beef up the material editor
*Fix the Shadow system
*Jitter in terrain system between terrain and models
*Add weather system
*Better snapping system
*Better Zip file functionality
*Re-add terrain erosion
*Add terrain specular, and if needs be, remove parallax from the terrain pass to make way for it, but retain parallax for shapes.
*Add the ability to set a kind of 'alpha mask' for the terrain tools, so you can set the strength & shape of the tools a bit more specifically.
*Add more flexibility in the noise tool again, maybe being able to set a tiled heightmap mask to it so you can again control the behaviour of it better depending on design requirements.
*Water... although i havent played around with it in recent builds, and it may have been changed since i have used it properly, the settings for water could really be simplified down to make it more user friendly, alot of the settings are awkwardly named considering their effects on the water blocks.
*A basic precipitation and particle library
*Add split screen "view ports"
*Better terrain materials manager
*Add a semi "auto-zone" widget kinda thing. for example selecting a building shape, and at click of a button, create a "zone" item matching its bounds etc.
*Ground Cover needs collision support
*Add terrain layer sensitivity to the forest
*Improve character import
*Add more keyboard shortcuts and show on the menu
*Light bleeding through the seems
*Possibly change the ground cover and forest editor to be 2 more generalized editors
*when standing outside of a zone, particles and lights are visible that are created inside of it. the only way that they should be visible is by looking inside the zone through a portal.
*Occlusion Volume. It should have a switch that allows it to effect the terrain behind it or not. As it stands, it causes the terrain to disappear behind it, which u dont always want.
*More 3D imports
*Artist friendly - add sliders along w numbers input
*SKYBOX and SCATTER SKY should work together somehow
*Better animation blending
This isn't about the latest DX/OGL or anything like that. What tools are missing compared to other engines out there right now that you feel would breathe new life into T3D-MIT and make development easier for you?
This is the list so far of issues or things that need added:
*Interior/structure designer like Constructor
*Prefab object that combines models and scripts
*Improve forest editor
*Beefing up the sketch tool
*Beef up the material editor
*Fix the Shadow system
*Jitter in terrain system between terrain and models
*Add weather system
*Better snapping system
*Better Zip file functionality
*Re-add terrain erosion
*Add terrain specular, and if needs be, remove parallax from the terrain pass to make way for it, but retain parallax for shapes.
*Add the ability to set a kind of 'alpha mask' for the terrain tools, so you can set the strength & shape of the tools a bit more specifically.
*Add more flexibility in the noise tool again, maybe being able to set a tiled heightmap mask to it so you can again control the behaviour of it better depending on design requirements.
*Water... although i havent played around with it in recent builds, and it may have been changed since i have used it properly, the settings for water could really be simplified down to make it more user friendly, alot of the settings are awkwardly named considering their effects on the water blocks.
*A basic precipitation and particle library
*Add split screen "view ports"
*Better terrain materials manager
*Add a semi "auto-zone" widget kinda thing. for example selecting a building shape, and at click of a button, create a "zone" item matching its bounds etc.
*Ground Cover needs collision support
*Add terrain layer sensitivity to the forest
*Improve character import
*Add more keyboard shortcuts and show on the menu
*Light bleeding through the seems
*Possibly change the ground cover and forest editor to be 2 more generalized editors
*when standing outside of a zone, particles and lights are visible that are created inside of it. the only way that they should be visible is by looking inside the zone through a portal.
*Occlusion Volume. It should have a switch that allows it to effect the terrain behind it or not. As it stands, it causes the terrain to disappear behind it, which u dont always want.
*More 3D imports
*Artist friendly - add sliders along w numbers input
*SKYBOX and SCATTER SKY should work together somehow
*Better animation blending
About the author
http://winterleafentertainment.com/
#42
11/11/2014 (6:17 pm)
I think we could remove the forest and groundcover all together if we move to an "objectReplicator" and an "objectBrush" 
#43
I think we should think about that too.
11/11/2014 (6:25 pm)
What about backward compatipility? A engin version change in a project would be a lot of work and need to set all trees and ground covers again.I think we should think about that too.
#44
11/11/2014 (7:41 pm)
Existing objects could be provided as modules for users that want to enable them specifically, but at some point backwards compatibility must be broken to allow for progress. 
#45
You'd just have additional options in the brushes for if they auto-paint, and if so, what materials they'd paint it on.
This would give you all the functionality of groundcover, while allowing you to still manually paint stuff as needed via the regular forest tools, without needlessly over-complicating things.
11/11/2014 (7:58 pm)
I'm of the mind of moving the main part of the GC functionality - the procedural placement based on surface texture - into the forest tool.You'd just have additional options in the brushes for if they auto-paint, and if so, what materials they'd paint it on.
This would give you all the functionality of groundcover, while allowing you to still manually paint stuff as needed via the regular forest tools, without needlessly over-complicating things.
#46
github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/En...
and
github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/En...
in case that gives folks notions.
11/11/2014 (9:06 pm)
RE: Forest Tool. Jotting down:github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/En...
and
github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/En...
in case that gives folks notions.
#47
exporting a conves shape cube to Collada from latest Torque and importing back again is messed up:
adding new functions to the sketch tool would be great as well. my 2 cents.
11/11/2014 (9:17 pm)
how about fixing the Collada Exporter option since it is still bugged? Should be a priority and will greatly benefit artists since this is a pipeline to exporting Convex Shapes using the Sketch toolexporting a conves shape cube to Collada from latest Torque and importing back again is messed up:
adding new functions to the sketch tool would be great as well. my 2 cents.
#48
11/13/2014 (4:16 am)
after chatting with our character artist last nite, i have a question... is character import as big of pain as it seems? by this i mean a fully animated, rigged ready to run model. is it this bad in all engines? 
#49
At the very least, if the whole system is merged into one TOOL in the editor, that's fine, but try to keep the actual handling/rendering of grass in it's own system and keep collision and shadows out of it.
11/13/2014 (5:14 am)
Just to toss a counter-argument in the ring for collidable ground cover. Ground cover, grass specifically, is technically challenging. It's thousands and thousands of small semi-transparent objects. There's overdraw issues, ugh, there's all kinds of issues. In my opinion it's a good idea to keep ground cover, for the usage of grass and such, as simple and contained as possible. It allows you optimize it better rather than fighting back and forth trying to balance features between trees and grass. At the very least, if the whole system is merged into one TOOL in the editor, that's fine, but try to keep the actual handling/rendering of grass in it's own system and keep collision and shadows out of it.
#50
11/13/2014 (7:05 am)
@Paul - it is by no means as bad as this in most other engines. The bad part is the actual "how to" documentation, though - it is difficult because it is not well documented. Once it is well documented it can be automated to a large extent I'm sure - as far as I'm aware there are node naming expectations, material naming expectations and a number of other "expectations" in almost every engine so I'm not even counting those (though they should have better docs as well). 
#51
11/13/2014 (7:06 am)
agree with Andrew, grass and forest should be separate. forest at the expense of rigid bodies, shoots down FPS (but the forest is more static) grass spawning dynamics often and quickly, it should be easy to load, many hundreds of times if you add in the grass physics this could be a mortal blow to the FPS 
#52
11/13/2014 (8:56 am)
I think the collision for groundcover was meant for using shapes, not with the grass billboards. 
#53
Yep, not for billboards. GroundCover is very dynamic, in that you can use an image or a shape. In the case of shapes having collision support would be great, but the designer would have to use care when placing said shapes with collisions enabled. I would never suggest anyone enable collisions for all the grass in a scene.
In any case, I did some testing and it's possible to accomplish 'ground cover' with collisions using a shapeReplicator object. Afaik, the shapeReplicator object doesn't use material masks though.
11/13/2014 (11:38 am)
Quote:I think the collision for groundcover was meant for using shapes, not with the grass billboards.
Yep, not for billboards. GroundCover is very dynamic, in that you can use an image or a shape. In the case of shapes having collision support would be great, but the designer would have to use care when placing said shapes with collisions enabled. I would never suggest anyone enable collisions for all the grass in a scene.
In any case, I did some testing and it's possible to accomplish 'ground cover' with collisions using a shapeReplicator object. Afaik, the shapeReplicator object doesn't use material masks though.
#54
@gamerx: Mind submitting a github issue so that doesn't get lost? (a console log would help as well if there's any errors that it spits out.)
11/13/2014 (11:47 am)
@jesse: Second link above is where the groundcover hooks into the terrain system to snag a material reference.@gamerx: Mind submitting a github issue so that doesn't get lost? (a console log would help as well if there's any errors that it spits out.)
#55
11/13/2014 (12:09 pm)
Oh, nice one Az. Appreciate it, this deserves a closer look.
#56
thanx man. I dont have an account there im just starting to play around with Torque but last time I checked someone alreasy submitted issue about this bug. https://github.com/GarageGames/Torque3D/issues/467
I think Torque has potential to be on top again with the popularity of BeamNG and Life is Feudal which got me back here, but this has got to be the most basic tool that you guys need to get fixed. If you google image 'udk bsp brushes" you can see that a lot of artisans makes use of sketch tool equivalent for unreal 3/udk. Anti-aliasing also needs to be upgraded too imho. It makes the whole scene blurry looking side-effect on a high resolution setup instead of improving the scene.
graphic wise I can say Torque can still impress but full lightmaping support and integration will help too. think unity = beast and udk = lightmass. help guides should also be updated with examples if possible.
I see a few members leaving here and now going to udk/unity maybe this is one of the reasons and a wake up call.
P.S. If you all can notice that the very first commenter on this thread Chrisdeboy mentioned this sketch tool/constructor topic, must be getting warmer..
11/13/2014 (5:44 pm)
@azaezelthanx man. I dont have an account there im just starting to play around with Torque but last time I checked someone alreasy submitted issue about this bug. https://github.com/GarageGames/Torque3D/issues/467
I think Torque has potential to be on top again with the popularity of BeamNG and Life is Feudal which got me back here, but this has got to be the most basic tool that you guys need to get fixed. If you google image 'udk bsp brushes" you can see that a lot of artisans makes use of sketch tool equivalent for unreal 3/udk. Anti-aliasing also needs to be upgraded too imho. It makes the whole scene blurry looking side-effect on a high resolution setup instead of improving the scene.
graphic wise I can say Torque can still impress but full lightmaping support and integration will help too. think unity = beast and udk = lightmass. help guides should also be updated with examples if possible.
I see a few members leaving here and now going to udk/unity maybe this is one of the reasons and a wake up call.
P.S. If you all can notice that the very first commenter on this thread Chrisdeboy mentioned this sketch tool/constructor topic, must be getting warmer..
#57
I've been quite unhappy at Torque's fuzzy shadows. Not sure if I just don't know how to tweak them properly, but they also seem not to work well when self-shadowing static shapes in some cases. Will dig up a screenshot later.
The convex editor is probably something we can work on. Maybe we should start a new thread for specific discussion/proposals, and decide what's highest priority and who's going to do it.
Another thing that's always bugged me. You can only get one level of hierarchy in your datablock folders. Also, according to the Reddit feedback, we should probably add the ability to search datablocks. And if the datablock editor is going to stay, we should implement 'immutable' fields, and a creator UI for datablocks. And, again, the ability to search datablock classes.
I'm also in favour of more keyboard shortcuts <3.
Random idea: Blender introduced a new spacebar menu where you can literally search for basically any operation. Like, you just press space and start typing. It's super helpful. Wonder if we should look into the same.
11/13/2014 (7:25 pm)
I'm not too familiar with how lightmapping works, but is this something we could do by integrating more tightly with Blender/Cycles? Having an all-open-source pipeline would be the best, and Cycles looks pretty great.I've been quite unhappy at Torque's fuzzy shadows. Not sure if I just don't know how to tweak them properly, but they also seem not to work well when self-shadowing static shapes in some cases. Will dig up a screenshot later.
The convex editor is probably something we can work on. Maybe we should start a new thread for specific discussion/proposals, and decide what's highest priority and who's going to do it.
Another thing that's always bugged me. You can only get one level of hierarchy in your datablock folders. Also, according to the Reddit feedback, we should probably add the ability to search datablocks. And if the datablock editor is going to stay, we should implement 'immutable' fields, and a creator UI for datablocks. And, again, the ability to search datablock classes.
I'm also in favour of more keyboard shortcuts <3.
Random idea: Blender introduced a new spacebar menu where you can literally search for basically any operation. Like, you just press space and start typing. It's super helpful. Wonder if we should look into the same.
#58
I recently stumbled on how to make shadows not fuzzy. In your ScatterSky datablock(if using a normal Sun object it's in the Sun datablock):
I do recommend perhaps a 'bit' of shadowSoftness but try out the example to see how it works =)
Also, yep I've noticed the same oddity with self-shadowing static shapes. Seems like it's only with Basic shadows and it goes away with Advanced shadows enabled.
P.S. That mention of the Blender spacebar function sounds like it could be awesome in Torque..
11/13/2014 (8:04 pm)
Quote:I've been quite unhappy at Torque's fuzzy shadows. Not sure if I just don't know how to tweak them properly, but they also seem not to work well when self-shadowing static shapes in some cases.
I recently stumbled on how to make shadows not fuzzy. In your ScatterSky datablock(if using a normal Sun object it's in the Sun datablock):
new ScatterSky() {
...
shadowType = "PSSM";
texSize = "2048"; // Increasing this offers 'smoother' edges
...
shadowSoftness = "0.0"; // Defaults to 0.25 to 'soften' the edges(fuzzy)
...
};I do recommend perhaps a 'bit' of shadowSoftness but try out the example to see how it works =)
Also, yep I've noticed the same oddity with self-shadowing static shapes. Seems like it's only with Basic shadows and it goes away with Advanced shadows enabled.
P.S. That mention of the Blender spacebar function sounds like it could be awesome in Torque..
#59
11/14/2014 (2:37 am)
This is what I'm seeing with advanced lighting shadows - the whole walls/floor is a single mesh:
Torque Owner Daniel Buckmaster
T3D Steering Committee