B5: noteworthy quarks/issues
by TheGasMan · in Torque 3D Professional · 09/07/2009 (3:40 am) · 13 replies
I'll just list them out...
(thumbnails are linked)
1. shadow passthroughs
The passthrough-shadow hits the top of the pipe, it hits the inside of the pipe and yet the pipe finally renders a shadow to the ground.
- not ideal in 90% of circumstances, perhaps we can get a toggle to allow/disallow this ? Keeping this as a toggle-able feature for objects that may need this capability would be a huge bonus to the engine feature list IMO. Of course a pipe does not need to have this type of passthrough but glass/acrylics would benefit.
2. skyboxes and scatterskies are occluded by zones
(- I don't see a reason for this unless the zones will receive the ability to allow or disallow the occluding of the sky entities. It's simply is bullish in it's current form.)
@@EDIT#1
Functional use: add a portal entity in between the view of the player and the opening to the sky. If the window and the portal are both in view at the same time...the sky is rendered. (I wonder if the sky is rendered whenever any portal is in the player pov. I would test that question but the engine freezes when I move portals around.)
@@
3. Decals on items that move
- As you see in the image, I shot a set of boxes, the decal wrapped, I moved the boxes, the decals did not follow. I would guess that having the decal grab the object transform is ideal but then I would say "what if there were multiple objects moving multiple directions ? More of my babbling: ..I would think you guys would give a function to allow/disallow decals on objects(which of course defaults to ON).
I know the decal issue was discussed on a few levels(players and wrapping to player) but I do not know if this specific area was discussed.
(thumbnails are linked)
1. shadow passthroughs
The passthrough-shadow hits the top of the pipe, it hits the inside of the pipe and yet the pipe finally renders a shadow to the ground.
- not ideal in 90% of circumstances, perhaps we can get a toggle to allow/disallow this ? Keeping this as a toggle-able feature for objects that may need this capability would be a huge bonus to the engine feature list IMO. Of course a pipe does not need to have this type of passthrough but glass/acrylics would benefit.
2. skyboxes and scatterskies are occluded by zones
(- I don't see a reason for this unless the zones will receive the ability to allow or disallow the occluding of the sky entities. It's simply is bullish in it's current form.)
@@EDIT#1
Functional use: add a portal entity in between the view of the player and the opening to the sky. If the window and the portal are both in view at the same time...the sky is rendered. (I wonder if the sky is rendered whenever any portal is in the player pov. I would test that question but the engine freezes when I move portals around.)
@@
3. Decals on items that move
- As you see in the image, I shot a set of boxes, the decal wrapped, I moved the boxes, the decals did not follow. I would guess that having the decal grab the object transform is ideal but then I would say "what if there were multiple objects moving multiple directions ? More of my babbling: ..I would think you guys would give a function to allow/disallow decals on objects(which of course defaults to ON).
I know the decal issue was discussed on a few levels(players and wrapping to player) but I do not know if this specific area was discussed.
About the author
gameartstore.com
Recent Threads
#2
The #2 solution sounds viable but I think that adding the portal to the zone causes more to occur than just allowing the sky to render. I'll run some tests.
[1 test I that I already did: I added a very small portal(think .2 .2 .2)to nearly any position in that zoned area seen in the picture...and the sky rendered. Now why would a portal, placed almost anywhere within a zone open the area to rendering the sky ? ..I would need to see the docs on this, but already it sounds a bit hairy and hacky.]
The #3 idea is just "ok". I find that to be a tad silly...it should just work.
09/07/2009 (4:47 am)
Thanks for the input Sir Picasso. ;)The #2 solution sounds viable but I think that adding the portal to the zone causes more to occur than just allowing the sky to render. I'll run some tests.
[1 test I that I already did: I added a very small portal(think .2 .2 .2)to nearly any position in that zoned area seen in the picture...and the sky rendered. Now why would a portal, placed almost anywhere within a zone open the area to rendering the sky ? ..I would need to see the docs on this, but already it sounds a bit hairy and hacky.]
The #3 idea is just "ok". I find that to be a tad silly...it should just work.
#3
The Sky/Clouds and other objects like that have a "global" bounding box, so, any portal to the outside zone will end up allowing them to render.
IMO this is a feature, to not have these type of objects render inside every zone. Rendering the ScatterSky or CloudLayer can be quite expensive, and if you are inside a building with no windows it is doing a lot of extra work. If you want them to be rendered you can add a portal from the window to outside.
#3
We do not have support for moving decals. But you can determine the type of objects a decal can be placed on. DecalData has an S32 member called clippingMasks. It is being initialized to STATIC_COLLISION_MASK in the constructor but you could change this or expose it as a field.
09/07/2009 (5:20 pm)
#2The Sky/Clouds and other objects like that have a "global" bounding box, so, any portal to the outside zone will end up allowing them to render.
IMO this is a feature, to not have these type of objects render inside every zone. Rendering the ScatterSky or CloudLayer can be quite expensive, and if you are inside a building with no windows it is doing a lot of extra work. If you want them to be rendered you can add a portal from the window to outside.
#3
We do not have support for moving decals. But you can determine the type of objects a decal can be placed on. DecalData has an S32 member called clippingMasks. It is being initialized to STATIC_COLLISION_MASK in the constructor but you could change this or expose it as a field.
#4
I agree with the reason and concept of the portal entity, I just think something is awry..however I can not test the portals due to the engine randomly freezing when I move them around.
I would like to continue this conversation if the portals & the engine ever cooperate. Argh! ..On second thought, I'll just wait for the docs.
09/07/2009 (8:25 pm)
#2 I agree with the reason and concept of the portal entity, I just think something is awry..however I can not test the portals due to the engine randomly freezing when I move them around.
I would like to continue this conversation if the portals & the engine ever cooperate. Argh! ..On second thought, I'll just wait for the docs.
#6
09/07/2009 (8:27 pm)
Actually, I just didn't understand #1 at all...
#7
-> Shadows do not normally pass through a solid metal pipe to be rendered inside of the pipe, do they ?
More if you need it:
The pipe has a shadow on top of it..that shadow is going through the top of the pipe and it is being shown on the inside of the pipe(it should not be doing this).
Edit: a better example of passing-through shadows.
09/07/2009 (8:36 pm)
James, click that image for the larger view.-> Shadows do not normally pass through a solid metal pipe to be rendered inside of the pipe, do they ?
More if you need it:
The pipe has a shadow on top of it..that shadow is going through the top of the pipe and it is being shown on the inside of the pipe(it should not be doing this).
Edit: a better example of passing-through shadows.
#8
This is a problem has been around forever in my own apps that used shadow mapping, infinite Shadow Volumes with scissor system was the best results like Nvidia and id use but like all shadows system Volumes have their downsides too.
You could fix this with overlay texture(or some other way) to force darken the inside, its a game right? Tweaks a million!
09/07/2009 (9:03 pm)
Shouldn't the self-shadow of the pipe darken the same area as the passing-thur shadow? This is a problem has been around forever in my own apps that used shadow mapping, infinite Shadow Volumes with scissor system was the best results like Nvidia and id use but like all shadows system Volumes have their downsides too.
You could fix this with overlay texture(or some other way) to force darken the inside, its a game right? Tweaks a million!
#10
(email in my profile)
09/07/2009 (11:00 pm)
@eb, can you provide reproduction info please? A mission file would be much appreciated if it's barebones enought to exhibit the issue without having to send a lot of stuff (it'd be fine probably to just send it with just the portals/zones and stock objects). Also, what do you think is awry that you mentioned aside from the freezing? Thanks :) Portal/zone bugs are tricky.(email in my profile)
#11
@Ross: For which issue do you need reproduction information ?
- I would like to talk about the portals but I don't have any real information on them to make any statements. ..I am mainly speaking from my intuition. Silly I know, but my hunches are usually pretty good. ;)
Here is what I can say about portals in default T3D demos:
- They cause random freezing when moving, rotating, scaling.
- I have had the engine freeze when I try to pass through a portal that I just placed(using the camera).
09/08/2009 (11:32 am)
I was half asleep when I posted this..otherwise I would have remembered to add in pertinent information. :X@Ross: For which issue do you need reproduction information ?
- I would like to talk about the portals but I don't have any real information on them to make any statements. ..I am mainly speaking from my intuition. Silly I know, but my hunches are usually pretty good. ;)
Here is what I can say about portals in default T3D demos:
- They cause random freezing when moving, rotating, scaling.
- I have had the engine freeze when I try to pass through a portal that I just placed(using the camera).
#12
09/09/2009 (6:03 pm)
@eb - Adjust the first parameter of the overDarkFactor on that light... its too weak causing it to leak light.
#13
09/09/2009 (6:45 pm)
Thx Tom. 
Torque Owner Ivan Mandzhukov
Liman3D
www.garagegames.com/community/forums/viewthread/100295
3.OK,i saw this bug on the movable pathshapes.
One of the ideas came across is to put:
the same idea as updateRenderChangesByParent();
in interpolatetick() of the decalManager
that will interpolate their transform,but i have not tested this yet.
It is far more complicated since transformation is created in sceneObject,decals not.
Decals are created on client.A ray cast hits the surface,we get the point+normal+tangent and create the decal there.So they are not intended to move.Their transform does not interpolate.
One of the ideas is to stop generation of decals on movable surfaces.
You can remove a decal using decalManagerRemoveDecal(decal_id)
Decals are added in updateActionThread()
There you can trigger them easily.