Decals Render on Collision Mesh, Not Rendered Geometry
by Ryan Mounts · in Torque 3D Professional · 09/29/2009 (8:19 pm) · 19 replies
For example, if I drop one of the provided trees into the scene and shoot the tree trunk with a rocket, the explosion decal is applied to the collision mesh (which is just a large cube) instead of just to the rendered geometry of the tree trunk.
Intel Core 2, ~1.99 Ghz
Nvidia Quadro NVS 135M
Intel Core 2, ~1.99 Ghz
Nvidia Quadro NVS 135M
#2
I suppose I'll just demote this thread from Bug status down to Discussion status.
09/29/2009 (11:40 pm)
I can live with that... when you know that's how it's meant to work, at least you can keep that in mind during the modeling process. Thanks for the info!I suppose I'll just demote this thread from Bug status down to Discussion status.
#3
Add this to the your art requirements list, heh.
09/29/2009 (11:56 pm)
Seems odd to me that this would of been the design decision, considering the focus of the art pipeline in T3D seemed to be allowing artists to create art without a lot of strict requirements or nuances to how they create that art.Add this to the your art requirements list, heh.
#4
To get that rendered decal result on the fence.. the first image,
does that mean you went through the tedious nature of supplying
a collision mesh for each individual picket in that fence, as
opposed to doing a single rectangular collison mesh encompassing
the whole fence?
... If You follow me ;)
Just curious.. coz when I have the time, Im always looking at ways to
"render".... display decals that might work.. yet go slightly against the grain..
Cheers !!!
Daniel
09/30/2009 (12:14 am)
Umm... Just a question there Michael!!!To get that rendered decal result on the fence.. the first image,
does that mean you went through the tedious nature of supplying
a collision mesh for each individual picket in that fence, as
opposed to doing a single rectangular collison mesh encompassing
the whole fence?
... If You follow me ;)
Just curious.. coz when I have the time, Im always looking at ways to
"render".... display decals that might work.. yet go slightly against the grain..
Cheers !!!
Daniel
#5
The 1st shot was the prior result of decals rendering upon the visual mesh of the fence. The 2nd is what they look like now when applied to the collision mesh :(
09/30/2009 (12:33 am)
@Daniel:The 1st shot was the prior result of decals rendering upon the visual mesh of the fence. The 2nd is what they look like now when applied to the collision mesh :(
#6
1. Where would you define if a decal is allowed on a particular surface or not? The specific case is disallowing decals on tree leaves or surfaces with alpha test which makes the decal look weird.
2. What do we do about bad performance cases... like a big decal cast on to a 10K poly model? Performance will not improve very much until DX11 is a reality. So do we just leave it up to the developer to be careful about where decals are allowed?
3. What about what type of decal to use on different types of surfaces? Where would you define that?
09/30/2009 (1:46 am)
So while your all in here...1. Where would you define if a decal is allowed on a particular surface or not? The specific case is disallowing decals on tree leaves or surfaces with alpha test which makes the decal look weird.
2. What do we do about bad performance cases... like a big decal cast on to a 10K poly model? Performance will not improve very much until DX11 is a reality. So do we just leave it up to the developer to be careful about where decals are allowed?
3. What about what type of decal to use on different types of surfaces? Where would you define that?
#7
In my opinion there are 3 potential decal states. 1) No decals, 2) Collision Decals, 3) Mesh Decals
If it'd be possible to control how the decal handled objects with those different values, that would be ideal. However, that may be not be possible.
For me, it depends on the game. In most situations I can assume that 95% of my objects are going to want to receive mesh decals versus collision decals, versus the 5% of my objects that may look funny with bad decals. I would rather deal with a bullet hole on a leaf, than deal with the way that an explosion decal looks on a fence.
So either way, it would be nice to either have the option as a whole across the mission, the engine, or the object. If it can be controlled in 1 of these 3 ways, then it can be adjusted per user, per level, per game.
For example on Burg, it'd be nice if it appeared on the mesh:
09/30/2009 (2:38 am)
I am not familiar enough with how the decal manager handles the geometry, so I'm unsure where we have the ability to check any information.In my opinion there are 3 potential decal states. 1) No decals, 2) Collision Decals, 3) Mesh Decals
If it'd be possible to control how the decal handled objects with those different values, that would be ideal. However, that may be not be possible.
For me, it depends on the game. In most situations I can assume that 95% of my objects are going to want to receive mesh decals versus collision decals, versus the 5% of my objects that may look funny with bad decals. I would rather deal with a bullet hole on a leaf, than deal with the way that an explosion decal looks on a fence.
So either way, it would be nice to either have the option as a whole across the mission, the engine, or the object. If it can be controlled in 1 of these 3 ways, then it can be adjusted per user, per level, per game.
For example on Burg, it'd be nice if it appeared on the mesh:
#8
edit:
one other hting is on the small steps under first lvl if you jump you will fly on the upper floor but you will still be under that floor.
09/30/2009 (3:31 am)
yes i seen this problem as well when testing Burg demo also there is other problems with the lighting going poof on some objects on that demo as well. they are there for 1 sec then gone the next.edit:
one other hting is on the small steps under first lvl if you jump you will fly on the upper floor but you will still be under that floor.
#9
Being able to specify no decals (None) on a per object level. As in, under no circumstances do we allow a decal on this thing. Being able to apply decals to the collision mesh Being able to apply decals to the visible mesh
Sometimes you just don't want a decal to show up on certain things. Tree foliage/leafs is a good example of this. The example of with the fence rails and/or the (large) explosion decal are just the easy examples (there are lots of others) of showing just how ugly that making/forcing all decals to the collision mesh can look. I do grant that better art can help to resolve this particular issue but I would still rather have mesh applied scorchmarks than be concerned about strange looking bullet holes in my tree leaves -- I've tried the explosion decal on a few trees/billboard-foliage and it's less jarring (to my eyes) than the blackened boxy smear hanging in midair because of the forced constraints of collision meshes.
If it was as simple as only being concerned about TSStatics then you could (should) add a "DecalLevel" option to the TSStatic class -- much like how the toggle for types of collision was added in order to use polysoup. We could be able to select either "No Decals", "ColMesh Decals", or "VisMesh Decals" and that would cover almost every problem object. Or, alternatively, just use the existing choice of collision type to determine where/how to apply decals.
But then that leaves the same issue unresolved for StaticShapes, and this is where I want it the most. Why not just add a new field to the class that gives the same type of choice outlined above for TSStatics. Set the field's default to collision mesh decal as it is currently, but then for those object types in which a more refined application of decals is preferred then we could simply add this one line to a datablock and be able to say "DecalLevel = None" for no decals or "DecalLevel = VisMesh" for mesh applied decals.
Maybe this would be easier to do through material settings?
Even just the option of being able to set (somehow/somewhere) an object/material to not receive decals would allow the designer more room to work with than the current option of forcing constraint to a collision mesh only.
Not all collision meshes are suitable, yet that leads to question 2 if we're using visible meshes...
It's projectiles or explosions that could make this tricky. The simplest solution (maybe?) would be to set up a series of faux materials for the real materials to use (or maybe add onto the Material Behaviors) -- much like how sounds and footpuffs are setup for the terrain -- and let the projectile/explosion make a choice. Said choice could then just be an array of "surface type" fields (in the projectile/explosion datablock) with suitable decal references to use based on what "type" of surface the decal is attempting to apply itself too. Maybe these surface types would have to be hard-coded and the designer would have to remember the order in which to setup their bullet-to-surface type array, or maybe you could even allow the surface types to be extended at will.
09/30/2009 (3:19 pm)
Quote:I suppose this is the only real tricky question. I kind of see it as needing three levels of control:
1. Where would you define if a decal is allowed on a particular surface or not? The specific case is disallowing decals on tree leaves or surfaces with alpha test which makes the decal look weird.
Sometimes you just don't want a decal to show up on certain things. Tree foliage/leafs is a good example of this. The example of with the fence rails and/or the (large) explosion decal are just the easy examples (there are lots of others) of showing just how ugly that making/forcing all decals to the collision mesh can look. I do grant that better art can help to resolve this particular issue but I would still rather have mesh applied scorchmarks than be concerned about strange looking bullet holes in my tree leaves -- I've tried the explosion decal on a few trees/billboard-foliage and it's less jarring (to my eyes) than the blackened boxy smear hanging in midair because of the forced constraints of collision meshes.
If it was as simple as only being concerned about TSStatics then you could (should) add a "DecalLevel" option to the TSStatic class -- much like how the toggle for types of collision was added in order to use polysoup. We could be able to select either "No Decals", "ColMesh Decals", or "VisMesh Decals" and that would cover almost every problem object. Or, alternatively, just use the existing choice of collision type to determine where/how to apply decals.
But then that leaves the same issue unresolved for StaticShapes, and this is where I want it the most. Why not just add a new field to the class that gives the same type of choice outlined above for TSStatics. Set the field's default to collision mesh decal as it is currently, but then for those object types in which a more refined application of decals is preferred then we could simply add this one line to a datablock and be able to say "DecalLevel = None" for no decals or "DecalLevel = VisMesh" for mesh applied decals.
Maybe this would be easier to do through material settings?
Even just the option of being able to set (somehow/somewhere) an object/material to not receive decals would allow the designer more room to work with than the current option of forcing constraint to a collision mesh only.
Not all collision meshes are suitable, yet that leads to question 2 if we're using visible meshes...
Quote:2. What do we do about bad performance cases... like a big decal cast on to a 10K poly model? Performance will not improve very much until DX11 is a reality. So do we just leave it up to the developer to be careful about where decals are allowed?Leave this up to the developer/artist/designer -- they're the ones who have to live with and justify their choices.
Quote:3. What about what type of decal to use on different types of surfaces? Where would you define that?I'm assuming this is in reference to be able to dynamically apply different types of decals on a surface based on what type of surface it is, ie. different bullet holes for wood/glass/metal/ground/etc. This is a non-issue for in-editor placed decals -- you make your choice when you place it. It's much the same solution for placing decals through code or script -- you make your choice when you place it.
It's projectiles or explosions that could make this tricky. The simplest solution (maybe?) would be to set up a series of faux materials for the real materials to use (or maybe add onto the Material Behaviors) -- much like how sounds and footpuffs are setup for the terrain -- and let the projectile/explosion make a choice. Said choice could then just be an array of "surface type" fields (in the projectile/explosion datablock) with suitable decal references to use based on what "type" of surface the decal is attempting to apply itself too. Maybe these surface types would have to be hard-coded and the designer would have to remember the order in which to setup their bullet-to-surface type array, or maybe you could even allow the surface types to be extended at will.
#10
It's lets the designer handle the special cases like the 10k poly model or a bad looking tree rather than forcing the whole system down a single path.
09/30/2009 (3:30 pm)
I agree with Michael. I think having the choice as to how they are applied is the best scenario. It's lets the designer handle the special cases like the 10k poly model or a bad looking tree rather than forcing the whole system down a single path.
#11
So what i'm gonna do for TSStatic is support a 'decalType' which will allow for the same options as the 'collsionType'.... None, Bounds, CollisionMesh, VisibleMesh.
If you do 'VisibleMesh' on a TSStatic that has a huge amount of polys... thats your problem.
I'm not gonna worry about interiors as its starting to be depreciated. Also gonna ignore ShapeBase as those objects are often animated or moving... not good for decals in general.
09/30/2009 (9:27 pm)
Ok.So what i'm gonna do for TSStatic is support a 'decalType' which will allow for the same options as the 'collsionType'.... None, Bounds, CollisionMesh, VisibleMesh.
If you do 'VisibleMesh' on a TSStatic that has a huge amount of polys... thats your problem.
I'm not gonna worry about interiors as its starting to be depreciated. Also gonna ignore ShapeBase as those objects are often animated or moving... not good for decals in general.
#12
If hardware could affect it, perhaps there should be a $pref level override, to force it down to collision or none across all objects?
09/30/2009 (9:33 pm)
Do we believe this could be an issue on different hardware depending on visible vs collision, or do we think it's mostly related to the geometry?If hardware could affect it, perhaps there should be a $pref level override, to force it down to collision or none across all objects?
#13
09/30/2009 (10:37 pm)
Clipping a lot of polygons to generate a decal is going to cost the same on most modern hardware (it is CPU limited and CPU performance has flattened out in the vast majority of computers sold these days).
#14
Could you clarify about ignoring ShapeBase objects. Do you mean no decals whatsoever on them and derived classes? I ask because StaticShapes do already receive decals.
But sounds great about TSStatics. Having options is cool, and just being able to choose "None" was what I was hoping for.
10/01/2009 (1:19 am)
@Tom:Could you clarify about ignoring ShapeBase objects. Do you mean no decals whatsoever on them and derived classes? I ask because StaticShapes do already receive decals.
But sounds great about TSStatics. Having options is cool, and just being able to choose "None" was what I was hoping for.
#15
Well StaticShapes may currently do decal clipping against the collision mesh. I'm not gonna alter that in any way.
Not sure what happens when your StaticShape is animated or mounted on to something that is dynamic. I guess you get a floating decal of some sort.
10/01/2009 (1:40 am)
@MichaelWell StaticShapes may currently do decal clipping against the collision mesh. I'm not gonna alter that in any way.
Not sure what happens when your StaticShape is animated or mounted on to something that is dynamic. I guess you get a floating decal of some sort.
#16
10/01/2009 (1:45 am)
Ah, that's a fair assessment of what happens actually. An option for "No Decals" would be cool there, but I won't press ;) 
#17
I believe its the prefered option, for myself, and it has been done, obviously.
Michael?
10/01/2009 (2:45 am)
so, in the end, maybe Michael could show us how to regain the effect from the first image? if we want to do it ourselves?I believe its the prefered option, for myself, and it has been done, obviously.
Michael?
#18
10/01/2009 (2:56 am)
I'm with Deepscratch and I would think 90% of us prefer it that way.
#19
10/01/2009 (3:45 am)
Would it make sense to have this as part of the 'behavioral' section of a material? Like footsteps, dust and impact sounds? That way we wouldn't need to tag each TSStatic if certain ones shared materials. Also, anything with a material would be able to define what kind of decals they allowed... Just a thought. 
Associate Michael Hall
Distracted...
I thought it was cooler to be able to do this:
Rather than this:
Interestingly enough, the counter argument was that it caused oddities with trees ;D
EDIT: Using a closer, "tighter" collision mesh would solve what you're showing -- it's this very thing which has held me back from porting and supporting the Kaboom! destroyables pack for Torque 3D.