I notice from forum posts, ISI's example mesh data, and Youtube videos that tracks are seemingly always built as single piece of geometry with the grass verge. Suppose we have a section of track - black is track, green is verge, with an exagerrated bump nearby, all polys having same smoothing group: View attachment 18384 A is the low-poly mesh. B is the way everyone seems to subdivide their track, but the red circle indicates one of many poles (vertices with more than four lines). Please correct me if I have it wrong but doesn't this lead to shading problems? I understand the underlying engine is all tris anyway, but geometry like this means you have "twisted" tris (tris with no two verts on the same plane)? C is the way of the warrior... D has been separated into 2 objects and the verge object is "hand-optimised" (adding loops to keep the geometry all quads), but of course those extra loops lead to the dangling verts circled in green which no longer match the track geometry, even though they are in the right location. there are no holes or overlap if you use control loops correctly. 1. Does any of this matter? Can you just get away with separte track, kerb and terrain objects that overlap (red is kerb)? View attachment 18385 2. If I wanted to build a (perfectly flat) 200m diameter skid pan, should I be thinking like this? View attachment 18386 Or more like this? Will that center vertex cause any issues further down the pipeline? View attachment 18387 Thanks for your thoughts!
D will increase the likelihood of flickering because you don't have welded seams. Best to correct verge geometry to flow out from track, like B, which reduces polygon count. If polygon counts aren't important, then C is smoother, but I'd certainly look for some efficiencies. On 1., the overlapping polygons keep the flickering at bay, but believe they create calculation overhead for the hidden polygons. Not sure how much it matters. There certainly are tracks that do it this way and they function. And many objects (houses) are placed in this manner. On 2., the latter example helps with graining the realroad texture. There might be some tiling artifacts at the center? Of course I'm no expert and I could easily have something wrong!
As Emery said, the reason most people do this is to get the verts to line up, so you don't get flickering, but keeps the road mesh relatively hi-res, and the terrain low res. In general, you should only have as much mesh density as you need to make the form without making it look too polygonal, but no more. So, since the road mesh generally need the density due to RealRoad interpolation between the verts, it is higher-res than the terrain (and than it would need to be for visuals). So, going by this philosophy, I would argue that what you have (I know it's just for example) isn't completely the right way to model this, though, since the bump is obviously very polygonal. I would keep the density in the mesh at the bump as you have it in C, but have it decimate as you move away from the areas of detail. Kinda like this (though, you probably don't need quite so many polys on the bump moving laterally across the bump) (NOTE: I didn't really take notice of what you did with D until after I photoshopped my version...so, imagine I'd used your bump from D instead ). View attachment 18393 There 'are' reasons for wanting to get verts to line up, even if they're separate objects/separate materials, etc. anyway, and will be broken apart when it's rendered. Like Emery said as well, there is a 'little bit' of overdraw going on with the pixel shaders, but most likely, for objects like these that usually take up a small part of the screen, it would be pretty minimal. The biggest reasons you'd want to get your verts to line up is for the aforementioned flickering potential, and if you're using vertex color/alpha for any sort of blending or baked AO--as the new Terrain shader uses vertex blending and baked AO, it is recommended to get it to match up to any opaque intersecting/bordering geometry (i.e. buildings, trees (but not billboards), curbs, fences, etc. That's a really good question, and one you could probably test for yourself, since you have the geo built already. My 'guess' is that the grid layout is going to be "better", but mostly just because you won't get a whole bunch of RealRoad buildup in the middle like you would with the radial layout. Granted, if nobody's driving across the middle, and they're mostly driving in circles, then the radial layout will probably be better. If you're not concerned with RealRoad, then go for the lower polycount version (assuming it's flat, anyway).
It shouldn't make a difference as to how the RealRoad texture is applied, as this should be handled by the artist. As I mentioned above, I 'think' the biggest issue is over-accumulation of RealRoad at the center, since it will accumulate from all directions--but this is only an issue if someone is driving over the middle a lot.
Many thanks for your comments. Aha! That did not occur to me! Of course now it makes perfect sense...I was worrying about flickering from overlapping geometry whereas what I should really be worrying about is ugly abrupt texture changes from overlapping geometry. Fair enough for most track situations, but I think I will have to live with that for at least some geometry transitions between objects built by different methods, as I can't see how I could re-topo this to have all the black loops line up with the red loops: View attachment 18394 View attachment 18395 Well OK, I could do it, but using classic subdiv methods without hand optimisation, the track surface would end up with lots of unneeded polys of unequal sizes (another no-no?). The track surface in those pics comprise a grid of about 10m x 10m polys - I've read elsewhere on the forum that I should be aiming for a track poly density nearer to 1.5m x 1.5m. I'm assuming for a perfectly flat pan I won't need as dense a surface mesh as that(?). For context, this is what I'm aiming for - a quick and dirty Max render using a (badly tiled) single planar 4k track texture. Thanks to Nuno for the (barely visible) kerb texture . View attachment 18396 If I did go with radial topology, I thought about putting a small hemispherical geosphere "kerb" in the centre to hide that pesky vertex. But if possible I would like to keep the centre clear to enable drivers to perform stopping distance tests and the like.
I think realroad is done at the surface resolution (calculated and stored), so the grid will be liable to aliasing of sorts with circle work, while very large polys may create huge areas of 'rubber' from cars running down the middle of them - not a great look if that's a consideration. I think you'd want the polys small enough that rubber basically goes only where cars go, instead of 5m to each side. A drying line on a wet track would probably be even worse.
Whoa...you mean...actually firing up gJED? <gulp> I know a little about 3D modeling for architectural visualization, but am a total noob when it comes to making game assets. Also I'm a newcomer to RF2 itself (never played/saw RF1). So I'm still missing lots of basic information about the workflow. I'm hoping and waiting for a kind soul to give us new-to-RF2 3D modelers a high-level overview of the gJED/FBX process, as the existing documentation that exists is often predicated on the old method using vintage 3dsmax plugins, and assumes a lot of prior knowledge of what all those config files do. I'm not complaining mind you, I realize gJED is still fairly new and the info I need IS contained in these forums, but currently spread out over dozens of threads, which can be discouraging for eager newcomers to modding. I'll try to combine some of my findings into a doc once I have some answers.
Thanks Lazza, that's exactly the sort of info I'm missing! Added to my List Of Things You Should Know Before You Even Start-Modeling
That was one of the first pages I read. End of first paragraph: "Much of the operation of gJED is similar to that of the latest gMotor2 plugins for 3DS Max." A perfectly concise and informative statement to a veteran, but a confusing one for a newcomer - "so...wait...LATEST plugins? didn't i just read you don't need them? do I still need them?" (I know the answers to these questions now, but it took some reading through this forum). Don't get me wrong, I like the whole "This is SPARTA!" attitude towards modding RF2. The PDF documentation is a model of brevity and concision. ...but a just a couple of sentences more explanation on the wiki would go a long way. A walk-through video on youtube of the pipeline from FBX to gJED to RF2 would be fantastic!
