Shadow bugs in interior
by Dennis Lamers · in Torque Game Engine · 07/03/2010 (9:31 am) · 6 replies
There we go again, Torque Constructor messed up my 3-weeks in progress city. I want to get this fixed, I have tried to re-export it on 1.0.1, 1.0.3 (and the one on 1.0.6) nothing worked. The shadows are still bugged! I don't want to start all over again, I am tired and nearly finished with my city!
http://www.peekarica.com/images/peekarica_059-00001.png
I hope somebody knows how to get the shadows correct. In Torque Constructor I don't see ANY glitch. So what is causing the problem? :S
http://www.peekarica.com/images/peekarica_059-00001.png
I hope somebody knows how to get the shadows correct. In Torque Constructor I don't see ANY glitch. So what is causing the problem? :S
About the author
Creator of Peekarica and Blockland Classic Mod.
#2
07/03/2010 (12:01 pm)
So when ever I make the city block and buildings two parts (in two scenes) will the shadows work then?
#3
It would be most efficient in both FPS and shadow quality if it were dissected into many different DIF's. I would do it by, foundations as one DIF, each building that is different into its own DIF, the bridge into a DIF.
Once you put them into the game engine you will play the part of level designer as you put the parts back together to build the city. You may also enjoy the added freedom of being able to use the buildings in far more complex ways then having them lumped together as ONE BSP. Also the fact, now each smaller DIF bush have room for far more artistic complexity then was ever possible before.
07/03/2010 (12:23 pm)
I am going by the assumption that your city is ONE DIF. It would be most efficient in both FPS and shadow quality if it were dissected into many different DIF's. I would do it by, foundations as one DIF, each building that is different into its own DIF, the bridge into a DIF.
Once you put them into the game engine you will play the part of level designer as you put the parts back together to build the city. You may also enjoy the added freedom of being able to use the buildings in far more complex ways then having them lumped together as ONE BSP. Also the fact, now each smaller DIF bush have room for far more artistic complexity then was ever possible before.
#4
Edit: It works, thank you. Well it is still strange that I can make a ship with 1000 brushes together, well I am very happy that this problem is fixed. Really thanks, she is a beautiful city now!



07/03/2010 (1:09 pm)
Yep, the city is now one huge dif. I go use this idea, and I hope this problem (could) be fixed. Now I know why GTA games has nearly 18,000 objects (example: buildings, roads) all in pieces.Edit: It works, thank you. Well it is still strange that I can make a ship with 1000 brushes together, well I am very happy that this problem is fixed. Really thanks, she is a beautiful city now!



#5
You seem to have made allot of progress over the last few months.
07/03/2010 (2:00 pm)
Perfect, looking really good. You seem to have made allot of progress over the last few months.
#6
07/04/2010 (1:18 am)
Thanks, the city is based on San Fierro from GTA San Andreas.
Torque 3D Owner Caylo Gypsyblood
This example picture is showing how BSP splits a large 'brush' into parts(Leaves in the partition tree list, often referred to as Nodes or Branches) for the Binary space partitioning tree. Quite often, without realizing it at all, the artist creating BSP geometry is effecting how the BSP is split, by intersecting one BSP 'branch' to another BSP 'branch', creating a much more mathematically complex BSP Tree.
As example, think of the example picture linked above as the foundation for a much more complex chunk of geometry, say a odd shaped castle, with walls a roof, and a few Spier Towers. Not only do the walls, roof and towers need to be split into the same BSP 'branch' as the foundation below them, but they also create even MORE complex BSP branching as the shapes are optimized into one BSP 'tree'.
Now the arch enemy of BSP are sharp pointed long triangular shapes derived from BSP splitting the geometry as effectively as mathematically possible. Often the floating point number representing theses points are infinity decimal point precise Like: 13.1324354657 . An BSP rendering engine will take a large decimal point precise number and round it down for the sake of speed and efficiency(Bit precision is a product of the BSP method used in the engine and the tool used to compile the BSP shape) so now it may end up being 13.13244. Now you can see that if we have many large decimal point precise numbers being 'chopped' we start to have problems with where the actual geometry is to be represented during game play, add to that a lightmap, and collision information and we have room for many odd unexpected errors.
The only recourse an BSP artist have is to try and keep BSP splitting in mind as the content is being designed. There are times that you know(or later discover) your geometry is going to cause problems. For such a case was designed the 'DETAIL' brush (As Torque call them), this is a geometry shape who is excluded from the main BSP Tree and calculated into its own BSP Tree, then 'planted' (if you will) into place on the main BSP tree. But even an 'DETAIL' brush must still full under the rules of normal BSP and will have the same type of failure as normal BSP geometry.
From your example picture I would think, exporting as many parts as possible into individual DIF files, and then putting them back together inside the Torque World Editor would help. Buildings and other shapes with odd angles that intersect each other would be the starting point for a first pass.