It doesn't work. I have a tire named "sign_tire01". I added a section to .gdb: sign_tire=(70, 25, 25, 20, 7000.0, 420.0, 0.8 ) In .scn : Instance=sign_tire01 { Moveable=True MeshFile=sign_tire01.gmt CollTarget=True HATTarget=False ShadowCaster=(Static, Solid) } And still no weight.
That looks technically correct though and I can't see any syntax error either. Are you sure you edited the .gdb of the right track configuration? Just to make sure, you could try using sign_pbarrier or one of the Spa ones. Perhaps sign_tire is triggering some specific type of feedback that's not finished/implemented yet. You can go much higher than a mass of 70 btw, I used 75 for my plastic barriers and hitting them at 150kph knocks you back to around 115kph. Or play with the spring/damper values. To avoid them flying all over the place high inertia values might be worth a thought too.
I need a suggestion about maps; We are working with very huge textures for the decals/paintings on airport area (Hammerhead, Followthru, Numbers, Arrows... etc..). To get a very crisp and smooth result I need of 4096px to cover 47mt (Width) of track...so to complete the entire area I think we need around 20*2 (diff/alpha + transitions maps) textures at this resolution for a total 170Mb of textures...to map the tarmac. Considering that we will working with huge textures for cement/grass areas as well...the question is: how to calculate GPU/VRAM impact before proceeding? PS: Many of these textures needs to be rasters images + alpha on flat panels (VS mapped lofts or EPS to polygons) to be really detailed...
I'd certainly model most of the paint, if not all of it. Because it's a runway, the painted areas are rather large. You'll want these to have a different TDF entry to simulate less grip when they're wet.
A different approach, maybe you can find an aspect or two that could help you out: - map the runways with a detailed base texture, tiled at 2m*2m to 4m*4m or therearbout - use "detail" maps with alpha blending for stuff like arrows or model them using the decal tag. An airfield would be one of the cases that feature was practically designed for. You could fit bars, arrows and the basic lines in a single 2048*2048 texture I guess, or even if need be with double the edge lengths - For transitions make use of vertex paint (also for darker patches of tarmac) and an alpha blending object to darken the edges/add the rubbered in areas from airplanes landing/starting.
This is 100% exactly what we're doing and this is because we need very high detailed maps. But modeling all the paintings needs tiling stuff...and we loose the possibility to have a lot of details around the track...:/
Model the lines as polys. Create one long white line texture (say 4096*256px or 128px) and map it to the polys you created. You won't need the full length so you can bring in variations by using UVW offsets on the lines. Say one line using the pixels from 0-1024, the other from 512-1536 and so on. Alternatively, make the white line texture say 75% opaque and all the detail from any underlying and tiled road textures will still shine through, in which case you could go even lower than that. The only element in your above example that would even make use of a higher resolution texture map is the 7. Everything else is perfectly aligned vertically or horizontally. And the 7 you can model perfectly from two of the stripes I described above.
Ok, this sounds good. I will model these white stripes and the 07 number...then I use one single map (512*4096) to fill the entire UV area. We will put along the vertical map some differences to create more details as the complete texture used before. This is the same method I used before for white/yellow lines around the external road...
If this do not cost to much in terms of FPS could be great! We have a lot of this paintings around the track..you know Dunsfold.
I've added RealRoad to quite sizable runoffs and it didn't instantly made my fps collapse. Essentially you have the choice between a) using huge textures, 170mb just for the basics as you said above, b) using RealRoad on the line/signage decals as well or c) having the lines and all not reflect at all. I know which one I would chose. And let's face it, just about anything you add will cost you at least a tiny bit of performance. Road surface and lines are among the absolute essentials in my book though, so if I had to cut down on details, I would do so elsewhere. On top of that, RealRoad is not that prohibitively expensive in terms of performance. If it were, we wouldn't be using it on the highest poly object in our tracks. If you want to keep the impact of adding it to the lines down, be conservative in the amount of polys you give the lines, especially on straight sections. Only give it more polys in areas where they curve (to make them look good and round) or where cars drive over them at an angle (to give the groove enough resolution in those areas). RealRoad works on the vertex level. The less vertices you have in the object, the less performance it costs doing RealRoad calculations for it. For the normal marking lines a single row of polys should be just fine. For the wide ones at the beginning and end of the landing strip using two rows of vertices increases the horizontal resolution of the racing groove a bit, to the point where I guess it would be just fine. Luc, please correct me if I'm wrong on any of the details about RealRoad.
I don't see a correlation between these choices... RealRoad....is it an alternative to a good texturing? No It Isn't. RealRoad gave me the groove line and the wet/marble FX on tarmac...and it's ok for me to use it. For now I'm following the Joesville_Section_rF2.max example and decals aren't made with RR method...
Well, there's a difference between a tiny painted line on a short oval and a huge painted area on a runway . In this case, I would opt for b) as well. Additionally, depending on the resolution of the RaceSurface mesh, I would also divide the paint polygons to make sure their resolution isn't lower than that of the underlying surface to prevent unwanted and unexpected RealRoad glitches (if that makes sense ).
Yep. I'm subdividing the polygons paint to obtain a similiar density as the road. BTW...If I use RR for this areas...how I can use alpha channels? I mean...this paintings should have irregular edges...irregular trasparency above the tarmac and other FX alpha correlated...but with RR method the alpha channel is dedicated to wet/specular effect... Using RR I can get only regular profiles...as the paint mesh.
Pure 0 alpha (maximum reflections, no spec) will be used where you want maximum transparency beyond the edges of the lines. they're fully transparent anyway, so that makes no difference. Non-zero alpha will make the surface react less to the wetness (pure white would not be desirable), but since there won't be any puddles on the paint, you can get away with a fairly solid colour in the alpha channel. Depending on the alpha channel of your road surface, you can lower the alpha channel level of the painted line. Some of the road will be shown underneath the paint, but you'll have enough control over the RealRoad reaction. It's a delicate balance, and a bit of a compromise. Another option would be to cut out the painted lines in the track geo (using a Boolean operation for instance), and adding an alpha blend overlay texture at the edges (select the edges, extrude and push) without using the RealRoad shader on these edges. This will allow you to use different detail maps for the painted road, and a subtle alpha based edge texture. This texture would have to be subtle to prevent unwanted glitches when the track becomes wet, so it's another delicate balance. finally, you can use the TDF's OnTop to remove the physical bump of the overlay, or simply make it a non-HAT object. The latter option would require a bit of extra texture work. I admit, your track is a bit of a special one ...
Can I get this kind of results using RR on lines? Honestly I want to be sure before converting all this stuff in RR... View attachment 1454
There will always be a compromise. Honestly, I suggest trying it on one piece, see what works and what doesn't. For this track, I really do recommend trying everything you can to make RealRoad work on those painted lines.
What aspect are you looking for from that screenshot? The texture detail? Not affected by RealRoad. Bump or specular detail? Not affected by RealRoad, in fact those texture stages are required by the shader at this point.
