[REL] Zolder Circuit

Great attention to details Wgeuze, keep up the good work.

 

But it helps.

 

After this building I have had enough of buildings for a while again and will do something about the smooth road, that helps even more

 

I have no track or car building skills but watching these threads and seeing you guys learn is fascinating and inspiring

Thank you for your continued work bringing top quality content to us

 

agreeed, as someone who is currently learning and building a few circuits it's great to see where other authors put the details in as it always inspires me to work harder to match the quality levels!

 

Glad to inspire you guys!

Thanks JKA

As promised I spent today on the road surface. According to video footage I added bumps where I figured they should be, added some logical ones in braking zones and
did a very small noise pass on top of that for more detail in the road itself in the Z-Axis, all those verts for realroad are there to use anyway, best have them do some
change in shape while they are there, even if it's minimal. On top of this, I increased the amplitude of the road noise, and doubled the length. Some people will get the chance
to test drive this over the course over the weekend. When they are happy with the result, I will make sure all the edges of the grass and kerbs meet up with the road again (as
there gaps now) and might do an alpha release again. This will not bring as much new things as you guys probably like but atleast you're not driving an ice road anymore.

Those absolutely adamant on driving this version as of today, can, if they want to, but I warn you to be dissapointed, it's really a test version aimed towards road feel and I
even accidentally removed all the walls from the track...

 

It's the little things..

So subtle, so rewarding

Small shadowy edge ^^

 

Pardon my stupidity but....what is it?

 

Looks like a test cube for ambient occlusion + normal map. Lower part of the cube looks 3d but it is just a flat surface. Nice wgeuze

 

Oh, ok. Nice work.

 

One of the things that are incredibly simple but add a lot to a scene. This little shadowy edge really 'plants' that object in the terrain/floor/world, even when in shadow. I've seen it done in the past but never took the couple of minutes to try it out for myself

Those guardrails have been annoying me for some time and as the road surface becomes more like it's final shape it seems appropriate I finish them. They are pretty high poly so every mesh will get 2 LOD meshes so they will not bog down performance on lower end pc's. Actually, I only mean to have the highest LOD visible on the highest graphics setting

A more practical example maybe Jamezinho this:


And a detail shot just for fun:


Now I'm going to work on the end pieces, I think I've identified two kinds, flattened out and 180 degree ones ^^
going into the oven, so to speak

 

I wouldn't recommend it.

More complex meshes seen from a distance can cause some aliasing artifacts and waste performance, because some polygons will have subpixel size.
Also, what seems like a reasonable polygon budget for single guard rail will look less attractive if you look at all guard rails on entire track. I once had a guardrail similar to yours and after putting in on portion of track I ended up with 100k polygons already. Could be spend elsewhere

In general (not just guard rails), two LOD's will suffice. Normal maps can provide surface shape information for low LOD.

And you will need collision meshes, too. To stay on the safe side - consider collision detection as very costly and use as simple collision meshes as you can (so, flat walls for guard rails, perhaps even with half the segments for curves).
If you have a wall with net - use just one box for it, not separate boxes for wall and net.


Other than that, you're doing a very good job with tesselation and ambient occlusion

 

I think you misunderstood my meaning there. What I will do is this:

Low settings: Lod 2 always
Medium Settings Lod 2 Lod 1
High settings: Lod 2 Lod 1 Lod 0

High or Full, whatever that will be, will be the only one to actually display the more detailed ones, for the low and medium I will not even bother displaying them so they can't hurt performance I don't know if it will be possible to have different distance settings per graphical setting but that is a care for later to be honest. First and foremost I'm catering to the maximum I can get out of the engine within limits, and optimize later (that isn't the most fun job).

None of my objects have collisions actually. In fact, I use a method I used in the Unreal3 Engine. In that case, we could create a separate mesh for a level, very low poly and optimized which had the sole purpose of doing collision detection. Visually, it wasn't even rendered on screen. As it is also one instance, it's pretty cheap on performance as well. I'm doing the same with zolder, where I for now have "Collision_Mesh_Main.gmt" with a collision flag doing all that work for me

Thanks ^^

edit:
Just for reference, this the main collision mesh. Not even optimized it's only 1900 triangles for the entire track including pitlane

 

Thanks for clarifying.

One more word on collision meshes. I'm not sure how rF2 engine handles them.

Whenever two objects are within range, collision detection algorithm must start processing them.
Now, if the collision algorithm breaks that mesh down into smaller pieces, it will only test these polygons that are within range of each other. If not, it will test all polygons.

If you have one big collision mesh for entire track, all cars are within range of this mesh at all times, forcing collision detection algorithm to work constantly.
So if this algorithm breaks this mesh down further, there's not that much of an issue here. If it doesn't, you're wasting a lot of CPU cycles, because cars will be tested against collision with polygons hundreds of meters away.

I'm not sure if you tested it (best with larger number of cars). It's definitely something to keep in mind, but like I said - I'm not sure how rF2 handles this.

 

My league is racing here at the end of March. Currently we are planning to use the other version of this track that is released. Any plans to get this version race ready before the end of March?

 

That is a good point you bring up, I'm also not sure how rF2 handles this and I'm doing this simply out of habit. It would be nice if someone in the know can clarify this. If need be, I can cut up the collision_main in chunks very easily
and have them either split into 500 meter long meshes or accommodate them to existing meshes (So for example guardrail_21_collision.gmt).

On the content side however, either way is fine as long as it is clear what rF2 likes best

Not even remotely, atleast not a finished state, sorry
That said, if you give me the ingredients of what you want out of a 'race ready' track, I can sure as heck give it a try on a functional level if you want but really the bare naked minimum. I would expect some hands on testing on your part to make sure
you get what you need and don't have nasty surprises come race day. Send me a pm with your skype tag, we might be able to sort something out, good for motivation to have a direct short term goal

 

Testing should give the answer.
Just run a lot of cars with single collision mesh and with let's say 30 collision meshes. If you use a lot of AI cars for this test, you should notice difference in either CPU usage or framerates.

If you see no difference, or difference is very small, then it would mean rF2 engine has it optimized at this level. If there is a huge difference, then we can get back to this subject and I will write some general advices as to how best split your collision meshes.

Best to run that test with both old and new collision model. The old one could have been left unoptimized with the new one coming. The new one could be unoptimized since it's still not finished

This is unlikely to have any impact on performance so do whatever is more convenient to you.

 

With the time available I don't see a point to do that any time soon, or maybe for a possible league release it pops up as an issue. If that is something I'm going to do it will have to be tested with a full grid I imagine anyway