About these ambient occlusion maps - it would be preferable to make them affect ambient light only, without affecting directional light. That's why it's called ambient occlusion in the first place. If for some reason, you will not be able to use shaders that support ambient occlusion maps, then you will be left with no other option than to use them as second texture layer. In this case they will affect both ambient and directional light, therefore their influence on object's appearance will be too great. So my suggestion is to decrease contrast on baked ambient occlusion textures, if you're going to use them in T0xT1 shader. I'm not sure if shaders with ambient occlusion work properly in current build. I know there were some problems with them before. If they work now, you should go for them and you will be able to used baked maps without further modifications.
Thanks for advice I use temporarily T0xT1 shader because only two shaders have AO slot, unfortunately both have hardcoded mapping channels. The same channel for diffuse and AO map.
Looking in my nvidia drivers under my rFactor2 profile it says "Ambient Occlusion - not supported for this application". View attachment 5211 Wondering if it will still work I wonder? Track looking great.
Postprocessing-based ambient occlusion algorithms are something I stay away from. Those are basically corner-shading algorithms, that have nothing to do with real ambient occlusion.
I was thinking about GI too. What do you think about this? Does it have any sense? I'm sorry, but release before Christmas is impossible.
Do you refer to global illumination? Game engine would have to support that. You only bake GI maps for games that have predefined time of day and weather conditions. In any other case GI has to be dynamic. AO maps are just masks for ambient lighting, just like shadowmaps are masks for directional lighting. GI maps are not masks - they're just baked lighting, so you can't use it in a racing simulation like rFactor 2.
Dynamic GI is out of the question for atleast a couple of years as we simply don't have the computing power needed. There is the use of fake screenspace ambient occlusion, but I really don't like the results of that, it makes everything look like a cutout or something. There always is some GI going on, and for use with dynamic wheather lke in rF2, it's best to keep the distances not too large, so you still have shadow creeping into the corners, while keeping them close to the shapes make them look good when it's fully lit. In that last instance, you mostly accept that shadow in creases for dirt instead of the shadows they are when done right (include some of this dirt and discoloration in your color map to benefit from this more) Speaking of directional lighting, is it possible to place lights inside the garages for example? If so you could have a neat combination of AO and directional light in there @feels building looks good, wondering how you will lay out the uv's. Can we build it like is usual in game engines or is there something out of the ordinary about this? I saw it requested before, but a shader reference might be nice to have at some point ^^ If I take that shaders' name literally I guess there can't be a normal and specular map? If so, is there an alternative to use which includes those two? Or can we store specular and ao in the alpha channels of T1 and T2 ? edit: and another question, would it be worth making a lod model for these kinds of buildings? Whats the triangle count you are looking at? Can't be much more than 7,5k-10k, right?
No point making a lod, it will just add an extra draw call that is not needed, you can split the model up by material and lod out higher detailed parts, like the Bailey bridge and the Pit building in LRP.
Fair point, negating the benefit of the lod in the first place there I'll investigate how you guys handled that later
No it won't Draw call is not performed for every object existing in the scene, but only for the ones that are actually drawn in given frame. It is what you're suggesting that may produce unnecessary draw call. If you extract detailed parts from mesh and put them into separate object with shorter LodOut distance, you will have to draw two objects at a time. It's better to have two complete meshes switched between, than two partial meshes that need to be drawn at the same time to produce complete building.
There is no point in making an entirely separate object when the whole of the original object is not a problem. The model will in most cases have multiple materials, so you mayaswell utilise the resources available and seperate the higher details from the model and lod them out. Plus separating out the details to a new object means you can skip it for lower detail levels. Constantly swapping meshes is not recommended. It uses less resources to simply just turn something off than to swap. Swap = in + out, out = out. With each of these little things you do to save resources, it opens the door to add more detail into other places. Don't look at it as just one object, look at it as the whole thing as a single unit, ie,, lets say you have 20 buildings with 2 materials each, that makes 40 draw calls. If you make replacement lods for all of them, then there are 20 in + out processes, if you separate the high details and just lod them out, there are only 20 out processes, that's half the amount of computation the engine has to endure. Now you have room for 20 more processes which you can use to add in more detail in other places. Which leads us back to the initial planning of the object itself. You need to think ahead and plan how things are going to fit together, keep all your fine details to a separate material so you can achieve this.
Ok, thanks for explanation. Nothing special here, you have to bake AO into texture and add into second layer and map this texture with any mapping method you like. I use AO texture for main parts of bulding and for small details I bake AO into vertex colour. You can use Specular Map T1 mul T2 or Gravel Traps shader (with normal and specular maps) and few others.
It really doesn't work like this in game engines. Nothing is actually being swapped. Meshes are being selected. If you have two meshes with dfferent LOD, one will be selected, one not, and one will be drawn. If you have two meshes, one with general building and other with details, one or two of them will be selected and one or two will be drawn. As you can see, in both cases engine must decide (select) if to draw either of two meshes, but in first case it will always draw only one, while in second case it may need to draw two. If you can put details on the same texture as the rest of the building, and use the same material, first option is better. If you can't, both options are more less equal. My preferred solution is to keep all objects in given area in one GMT file (as long as other requirements don't force you to do otherwise - like omnilights, collision detection, moveable objects). This way you can make LODB for entire area. The beauty of it is that you can use one material for all objects in LODB mesh and just bake textures from LODA mesh into it. So you're pretty much increasing number of materials, meshes and textures in scene, but at the same tme you decrease number of meshes and materials (and therefore draw calls) nedeed to draw one frame.
