prop_statics and face normals [solved] & odd measures...???
Quote from neco on July 31, 2011, 5:18 amHi all, here I go:
All faces for the models seem to be single sided (as far as I can see so far), only visible from one side and transparent from the other, face normals pointing outwards. For most objects this is quite reasonable in terms of calculating less polys.
However, when creating a gel dropper using the 'tube_paint_256a.mdl' model, I found it rather ugly that you could see the geometry behind the tube. The 'underground_paintdropper.mdl' hasn't got the issue, since it has visible face normals from both sides and works fine.
I tried to find a workaround by creating a hollow cylinder which I textured inside with a rusty material and "nodrawed' on the outside. I had to use the carving method for this (I know it's a no no).
Well, the whole thing now looks perfect from the inside but the 'tube_paint_256a.mdl' model looks dark and seems not to receive any light.
I have to point out that the inner cylinder doesn't touch the outside model tube it looks as if it should work perfectly in Hammer but not after being rendered in game. Why does the inner cylinder affect the appearance of the outer model?
Any ideas what might cause the lighting error???Also, my second question why did Valve choose to use those odd measures for their models. It is annoying to fit things like beams, frames, light covers etc to the rest of the brush geometry. As far as I can see problems especially occur when rotating groups which also include props. Is there a reason I can't see for doing this. It would be so easy if they would have kept to the grid sizes.
For example why is one of the truss models 32.5 by 128.5 instead of simply 32 by 128? Or even worse a railing is 128.5 by 42 (the height is 62 btw), a width of 8 for example would have made things much easier. I simply would like to understand. Why not making things like LEGO does?Thanks in advance...
Edit: Just added a screenshot for better understanding and illustrating the above problem. Will add an ingame screenshot soon.
Hi all, here I go:
All faces for the models seem to be single sided (as far as I can see so far), only visible from one side and transparent from the other, face normals pointing outwards. For most objects this is quite reasonable in terms of calculating less polys.
However, when creating a gel dropper using the 'tube_paint_256a.mdl' model, I found it rather ugly that you could see the geometry behind the tube. The 'underground_paintdropper.mdl' hasn't got the issue, since it has visible face normals from both sides and works fine.
I tried to find a workaround by creating a hollow cylinder which I textured inside with a rusty material and "nodrawed' on the outside. I had to use the carving method for this (I know it's a no no).
Well, the whole thing now looks perfect from the inside but the 'tube_paint_256a.mdl' model looks dark and seems not to receive any light.
I have to point out that the inner cylinder doesn't touch the outside model tube it looks as if it should work perfectly in Hammer but not after being rendered in game. Why does the inner cylinder affect the appearance of the outer model?
Any ideas what might cause the lighting error???
Also, my second question why did Valve choose to use those odd measures for their models. It is annoying to fit things like beams, frames, light covers etc to the rest of the brush geometry. As far as I can see problems especially occur when rotating groups which also include props. Is there a reason I can't see for doing this. It would be so easy if they would have kept to the grid sizes.
For example why is one of the truss models 32.5 by 128.5 instead of simply 32 by 128? Or even worse a railing is 128.5 by 42 (the height is 62 btw), a width of 8 for example would have made things much easier. I simply would like to understand. Why not making things like LEGO does?
Thanks in advance...
Edit: Just added a screenshot for better understanding and illustrating the above problem. Will add an ingame screenshot soon.
Quote from neco on July 31, 2011, 6:07 amOh okay, have solved the issue. It works perfectly when using a prop_dynamic instead. Should have tried that earlier.
However, can anyone explain this or give a detailed list of cases in which a prop_dynamic should be preferred? I thought that the only difference is the animation option until now.
Oh okay, have solved the issue. It works perfectly when using a prop_dynamic instead. Should have tried that earlier.
However, can anyone explain this or give a detailed list of cases in which a prop_dynamic should be preferred? I thought that the only difference is the animation option until now.
Quote from WinstonSmith on July 31, 2011, 12:34 pmFirst of all, what I gather from your post is that the paint tubes are transparent from the inside, and therefore when you look up through the dropper model you can see straight through. There's a dedicated model to solve this: filter for "paint" and look for model names with "cap" in them. They go just above the dropper and inside the tube so that it seals off the visibility. Make sure you set its (and the tube models') solidity to Never Solid so that the paint actually works if the info_paint_sprayer is above the dropper model.
On another note, the models don't actually have dimensions of, say, 128.5. It's actually 128, which means it lines up perfectly with the grid. It's just something odd with the bounding box of the model that makes it show up as slightly larger.
First of all, what I gather from your post is that the paint tubes are transparent from the inside, and therefore when you look up through the dropper model you can see straight through. There's a dedicated model to solve this: filter for "paint" and look for model names with "cap" in them. They go just above the dropper and inside the tube so that it seals off the visibility. Make sure you set its (and the tube models') solidity to Never Solid so that the paint actually works if the info_paint_sprayer is above the dropper model.
On another note, the models don't actually have dimensions of, say, 128.5. It's actually 128, which means it lines up perfectly with the grid. It's just something odd with the bounding box of the model that makes it show up as slightly larger.
Quote from neco on July 31, 2011, 3:42 pmThank you very much, I guessed there must be a better solution than my crappy carved brush solution.
I assume that this goes for the transparent ones as well. Will browse for those, too.
I understand the bounding box explanation, however I am not sure, yet, if it couldn't have been better than that. The problem still remains with some models, since I always try to keep brush sizes to the power of 2 (hope this is the way it is put correctly in English).
What I mean is that when I have let's say a handrail then I would expect parts of it to be 32, 64, 128 etc.
Anyways, it works the way it is and that's good enough, I think...
Thank you very much, I guessed there must be a better solution than my crappy carved brush solution.
I assume that this goes for the transparent ones as well. Will browse for those, too.
I understand the bounding box explanation, however I am not sure, yet, if it couldn't have been better than that. The problem still remains with some models, since I always try to keep brush sizes to the power of 2 (hope this is the way it is put correctly in English).
What I mean is that when I have let's say a handrail then I would expect parts of it to be 32, 64, 128 etc.
Anyways, it works the way it is and that's good enough, I think...
Quote from WinstonSmith on July 31, 2011, 3:47 pmThe handrail models themselves do come in sizes like that; there are lengths of 32, 64, 128, 256, etc. The bounding selection boxes in Hammer, however, go about .5 units outside of the model itself. This doesn't matter, though, because when you move the model around in Hammer the model itself's edges still align precisely to the grid.
The handrail models themselves do come in sizes like that; there are lengths of 32, 64, 128, 256, etc. The bounding selection boxes in Hammer, however, go about .5 units outside of the model itself. This doesn't matter, though, because when you move the model around in Hammer the model itself's edges still align precisely to the grid.

