RBR - sobject fencing not showing up in-game

[Pangaea]

Hey there.

Ive been placing sobject fencing about my track.. everything looks great in btb, but when playing rbr im starting to notice fences arbitrarily dissapearing. .. not right there and then, i mean its like the game never loaded them. But yet other times I play the game they display. Also sometimes a fence might only appear as one panel.. just on its own. Its, odd as, one min its ok on rbr,, then export again (without making any changes) and some dissapear.

Its not a lod problem.. or sobject attribute.. just totally random in the game...
(ive also delete whole sections of fencing and put them in again from scratch)
its not a terrain grounding problem, or anything else i can think of
as i said, its looks fine in btb always, and in rbr looks fine, but "sometimes" isnt there , or one panel of fencing is there.
It seems to be happening with fences ive placed later on in my project rather then ones i placed a while ago.

I relise beacuse of the randomness of this, it might be hard for somone to help me, but has this issue come up before for anyone?

I also noticed it a couple of times while making my last track, but this track its happening more often.

 

[Paul Minnaar]

could be that you have the fence the wrong way around. Just grab a node point and rotate the fence completely around. I noticed once that the textures only render from one side

 

[martinez]

Check if you use objects that are parts of these SObjects and they are collidable. Or you made the Strings collidable and have somewhere single objects from them as non-collidable.
There's a well known bug in BTB 8.0.3 about using collidable and non-collidable instances of the same objects at the same time. This appears also in SObjects, since they are made from "regular" Objects.

Let me make it clearly - say you put into the scene two rocks of one type (e.g. Rock_03 is the name). If you set one of them collidable and the second not - one of them will disapear in the game.
The solution could be duplicate the object in xpack (with some different name, maybe Rock_03_col) and then you have two objects that look the same, but they are not the same for btb
Duplicate - means load the object twice into xpack - change name first time.

 

[Kyle Puttifer]

I had a problem while making a drag strip (4km long). The walls and grandstands were all 4km long, and flickered in rfactor. After deleting them and redrawing them into smaller pieces, this problem disappeared.

 

[Pangaea]

thanks folks.. i never solved this but moved on using another fence sobject for the mean time.

"There's a well known bug in BTB 8.0.3 about using collidable and non-collidable instances of the same objects at the same time. This appears also in SObjects, since they are made from "regular" Objects."

this is making some sense to me i think.. there is one "Problem" fence that i have set to non-collide ( to help optimise performance), but there is a small section of this fence that was going over a bridge, so i decided to put like a "base" at the bottom of the fence pole and make it collidable. so the base (green default bin object) is probably where the problem has arisen.. Although this is now happening with other fences that are not near to any other type of object, i do believe this whole issue started when i made those post bases.

Sounds like your in the right area martinz... as usual

 

[martinez]

@ Kyle, you can also divide Walls by adding Material Change cross-sections. For 4km Wall - maybe add it in every 250-500 m. Then if you set LOD Out for the whole Wall like 200 m, the game will render it in parts (I guess you are not able to see any object that is placed more than 1500 m from the point of view).
The funny thing once was when I built "protecting" (from falling into the space) walls in RBR track. The walls were very long (8km), they had long panel length (100m), material change like 200 m... and LOD Out as 1 (m). Finally the material for them was transparent texture (so my task was to minimize rendering as much as possible), but when I was testing that use of Material Change cross-sections with non-transparent texture to see how it worked - they appeared earlier - about 100 meters before I reached them Looked like the material change length also affected the LOD.

When you divide a Wall with that Mat.Change cross-sections, you will have still one Wall in the BTB's wall's list, but if you check you gmt's (or objectlist.ini file for RBR), you will see there's more walls. So, that works like this

@ Pangea - I wasn't the first who discovered the bug So, if your fence (SObject) consists of post (a bin) and some wires - when you place the String and set it as not collidable, and in some other place you put just bin and set it as collidable - the problem comes.

I use collides only for stones and very rarely for some other (like tyres). I will have to remember exactly what kind of objects are collidable, so I make for them another slot in btb's object's list and name it accordingly. For the rest I use another low-poly collidable objects with transparent material and LOD Out = 1. You can use my xpack from RD Downloads or make your own. Only thing I need to do at the end is to replace the texture in exported files for one that has an alpha channel to make it invisible. The "replacing" texture is placed inside the xpack, so just extract it outside and keep it ready
Also, I build another walls to make fences collidable and they have the same transparent material as the rest of collisions cones/objects. With the texture used as material for collisions - all of the objects (and walls) are visible, because the alpha channel was deleted.
Notify that setting an object as collidable will make the machine to calculate collisions for all of it's meshes, so I believe it is still better to add new objects that are low poly to help the track's performance.
So, protecting walls and "collisions" are the last things I add to the track