Right, although the T1 Stamp Vertex once currently only have one texture stage in them, so the issue is more that you can't change the mapping rather than the mapping channel. I added some shaders to the list after another quick browsing of the list. Some shaders have notes and at least for the Bump Specular Map T1 lerp T2 add T3 Vertex Alpha Mask T2 shader it is explicitly mentioned that some stages share mapping channels.
I didn't mean T1 - Bump Specular Map AO Map T1 Stamp Vertex - Bump Specular Map T1 Billboard Normal Plus few others, but I don't remember exactly.
Maybe I'm wrong, but I remember in very early builds each different shader was loading correct channels. Now when you load a RR shader all stages are set to channel 1, at least in my 3D max. Same for other shaders... When I started working on Dunsfold I remember the RR shader was calling for correct channels (so, no need to tweak anything)...pretty sure about that.
I added the ones you mentioned to the list feels3, thanks for pointing them out. Tuttle, yes, that's excactly the behaviour we're talking about. No matter what setting you use in 3ds max, the sim/exporter will not let you set different mapping channels than the pre-defined ones. For example a downside to this is that you can not put the mult and specular stages of the RealRoad shader on different mapping channels, they are always on the same channel. If you were to set one to channel 4 and the other to 5, the sim/exporter would revert both back to mapping channel 2.
Yeah, but could be better to see what channel a stage is using @ default (even if it's hardcoded); this helps a bit more (especially for noobs) to visualize how the shader is managing mappings. Now everything you see it's just CH.1, so if you don't know exactly how the shader is managing HC channels you've much more issues in find the proper UVW procedure, as already said, especially for people who's learning modding.
Hi guys, I have small issue with Poznan Circuit. I noticed heavy stuttering when I drive through the pit lane (lots of details around) and I thought it's because I have to many polys/details/materials etc. but in free cam mode, FPS are stable, smooth and at least two times better. Any ideas?
Frecam mode in the proper sim or in Dev mode/the Viewer? If not in the proper sim, are there any settings different between the modes? What's your VRAM usage? If the sim has to move textures between VRAM and your normal RAM that can cause slow-downs in the weirdest spots, I had that at Fuji in places where performance should have been best based on poly count in that area. Are you LODing complex objects in that area?
@Johannes Rojola I wll check this today. @ethone VRAM usage is similar to Lime Rock. I did that test with only one car on track so I think it's far from the limit (I have 1GB VRAM, 32GB RAM) The weirdest thing is that FPS are very good in the same place in free cam mode when I don't drive a car. I don't have LODs yet. It happens in devmode and in proper sim.
Subtle stuttering may occur on CPU and GPU, but heavy stuttering is usually related to CPU being overloaded with something. When you say "free cam" - do you mean game is paused or in replay mode, or free cam while driving? Because perhaps it's not camera - related, but physics-related. If everything is fine on replay, then I'd blame collision detection - too large or too complex collision models will consume CPU time. For rendering, it's better to combine smaller objects into bigger ones, but for collisions it's better to split big object into smaller ones. So the best way is to have separate meshes for collisions. Not only you can split / arrange them better, but you may also simplify collision meshes (and I recommend simplifying them ridiculously ). But if it seems camera-related, then advice on lod multipliers is something I'd follow first.
That is exactly my impression of the problem. I've run into this problem with rF1 and rF2. My workaround is remove any collision detection from complex objects (like hi-poly tire barriers) and create separate non-renderable (but collideable) collision poly and place it right next to the complex object. Collision poly can be simple plane or very low-poly copy of original object and it has to have mapping coords for export. For instance, with straight tirebarriers I use single poly, which is burried about 10 cm inside visible barrier outer edge. Material is same as visible tire barrier. Cheers!
While we're talking about it and since we're now slowly introducing 3d guardrails: Those are prime examples of where you want a non-render but collision object like Jka described. They can put a huge stress on the CPU due to the high poly count and complicated structure, while they can be simplified a lot into a simple "wall"-type object for collision purposes.
Problem solved. I had very big parts of realroad and terrain. I cut them on smaller parts and it works now. Thanks for your help guys. I would like to give you positive rep, but Tim removed this interesting feature
hey guys, I have small problem with AI. I noticed this after longer sting with AI. AI don't want to park in the pit lane, only drives through the pitlane (with very low speed, far from limit set in GDB) and few meters away they are out of fuel. EDIT: problem solved