No, it doesn't work this way. All textures are put into video memory when track is loaded and they stay there. It doesn't matter if you use one bigger or several smaller.
@K... Just the horizon, or are ALL track textures are always loaded? I probably should start slotting some time in to read about nvidia architecture, and what you have to write to display these things we build..... too many info gaps having dived into the middle of this with modding. I hear that writing shaders is much like C. (?) Is it more like flat C, or more like C# (oo, gc, lambda exp, parallel extensions, etc..)? Are there any good 'first reads' on the subject you would recomend? @CodeF1 I went and looked through a bunch of old saved posts (RSC, RD, etc..) and got a couple clues. Also dug up my skybox directory and found a bunch of .xcf files (Gimp native), so I'm going to start with these original (larger) textures, and go through the process again so as to have my masters in psd format, higher res horizon dds images, and also, find out the original cause of our anomalies.... From this thread, it sounds as though single image is the way to go. I'm still curious what is causing this tex wrap though. [film at 11...]
All geometry and textures are loaded to video memory when game loads a level (in this case - when you load a track). They're all there untill you leave track back to menu. There are exceptions - games with large environments often use some kind of streaming technologies but not racing simulators. The thing with modding is that ISI uses pretty low-level tools. So instead of just modelling, texturing and setting optical properties of various materials, you must deal with all these settings that are unfamiliar to you. As for reading - it's difficult to point you any direction. Most of that stuff is actually meant for programmers, so while teaching you how to program 3D graphics, it doesn't really familiarize you with optimization strategies. These you learn by following documentation and guidelines provided by NVIDIA and AMD. That's why it's up to programmers to tell artists how to properly design content. I'm working on one such document for modders, but it will be a while. I know a lot about graphics programming, but I must also spend some time doing various tests on rF2 just to know what kind of optimizations are there, and what kind of optimizations modders must do themselves.
Actually, I read a GDC paper from Turn10 that explained their streaming system for Forza. Whether we want to classify it as a "simulation" is a whole other discussion altogether, but I just wanted to mention that to dispel the notion that all racing/driving software loads everything into memory from the start. But yes, for our purposes for rF2, everything is loaded in when the track loads as K Szczech said.
It's just frustrating working on something without access the source code and schematics. Nice to not be responsible for it, though. I'll start spending some time on the nvidia docs as a start. Thanks for the pointers. Re: K's post above... I look forward to your document for modders. I thought that your (and Luc's) discussion on textures in the wishlist sub was great. If you could expand on some of that in your modders doc it would really help a bunch of people here. [.... particularly: removing lighting from the diffuse tex, so it can be reapplied by the shader dynamically..] Thanks again for that post.
That's because it had to run on a console. This means much less video memory and therefore streaming. On PC you had streaming in games like Gothic 3, but that was quite a large environment.
Still testing things, and googling til blue on our "lines between horizon tiles" problem. Good to know that single image will probably fix the horizon issue, but I don't want to have it come up again like it did with Jka's trees. Today, I'll try K's suggestion about manually adjusting coords, then will look at what ethone said about settings.... one being nvidia's 'Transparency Antialiasing' .... and 'Adaptive Antialiasing' (smooths edges of tex that use transparency) .... already made sure images have no mips, and materials are set to no mips, and tex saved with no mips. It just dosen't seem to 'clamp' when unchecking 'tile' in tex properties. I read some posts by people writing max plugins that were saying for certain versions of max, there was a bug with the y coord, and they needed to explicitly set some '.clamp' param. Also found way too many (irritating) posts about other engine's exporters having a "clamp" check-box. ... damn... I have about 1 day's worth of hope left (testing wise)... . after that... I'm with Jka, and will wait for ISI to tell us how, or fix it if necessary.
OK.. I've tried everything mentioned so far in this thread... plus a few extras.... with no success. When I tried making a single image (for a 16 panel horizon... 8192 x 512), the exporter said it was an "illegal image size", and would not take it. So I tried 8192 x 8192.... Still illegal. It did take 4096 x 256, but that's loss of half the resolution... as the original 16 panels were 512 x 512. So I went back to the original 512 x 512 UVW "Face" mapped onto each quad .... and for each panel, put a uvw xform on it, set U Tile = .996 and then set U Offset = .002 then collapse, and go to the next quad etc.... Bit of a pain.... but looks great... no gaps, no lines, no longer in a rush for a real answer to this problem.
You can circumvent that illegal image size by replacing the 4096x256 one with the larger one after exporting. rF2 itself doesn't care, only the exporter does.
Hi Bink - yes I played a bit over the weekend with it myself. The one image works fine but what I find strange is that the one big image mapped over all the faces looks less detailed than the smaller images mapped onto each face, although the size of all the smaller images adds up to the size of the big image. How many mip maps did you try to create? I get this error if I try to create to many mip maps for the image for example if I create 10 mips for a 256x256 image. Bring it down to 6 and it is fine. With that image dimensions your probably don't even need mips? (BTW after seeing Ethone's post - I get this when I actually launches the game, not in the exporter) I am going to try this tonight when I get home. The only problem I have with the skyboxi and HDR is the fact that it is too dark on the "shadow side" and way too blueish on the "sunny side". I solved the "shawdow side" by "opening up" the top of the cylinder a bit so it looks more like a cone now but cant get rid of the blueish issue yet.
Actually I wouldn't go for 8192 and it's good exporter disallows it. Minimum system specs for rF2 say: You shouldn't go above 4096 unless you want your track to have problems running on some systems. If you need more use one of two techniques I previously described. You can put your 8192x512 texture into 4096x1024 texture. Using a quality DXT1 compressor would be recommended aswell to save videom memory and gain performance (texture compression decreases memory throughput requirements for rendering).
No worries, all I used the huge texture for was a test case. A guardrail actually, which as you'll notice hardly needs a 8192xanything texture. VRAM is something I'm really looking out for since the issue that came up with the environment maps.
@CodeF1... You asked about mip maps. From what I read, we are not suppose to use them on horizons. So when you export from ps, set the nvidia export plugin to 'no mipmaps' (or none... whatever it says..)...., and also in max (under texture properties, Mip Mapping..."None" radio button set). I think it was mia who said... for horizons, Under Texture Properties: "No Compression" (check-box checked) "No Detail Reduction" (check-box checked) Another post I found (elsewhere) said that for horizon images you should have the "No Z-Buffer" (check-box checked). I'm not sure if this is proper... so perhaps K, ethone, or blakboks can verify this. Also... I read that "move" in the exporter needs to be checked. (?) [On big tracks, anyhow, the horizon 'follows you around and over' your circuit.] @ethone... Good to know about not exporting 8192 ... but ... rf2 accepting it. Thanks. [about the image attached below...] I'd be curious to know what everyone thinks about building the horizon ring cone shaped, as CodeF1 said above. I've been doing my horizon as a cone-slice for a few years now, and find it good for the following reasons: 1. The light hits it 'better' (i know... pretty subjective).. 2. Since it's now lit, you can make it smooth (NO pointy normals).. 3. Also works well with big track, and massive elevation changes.... 4. Gives the sense that you have some ground under you .. Again.... If you know of reasons to Not do this .... let us know. Feel free to thrash. It would be good to know what else it may affect adversely. The one in the picture is about 3km up to about 5km in diameter. View attachment 3748
