Partialy you have right. If you do extreme programming, it may be true at beginning. In most cases of game devel there are developer co. and publisher co (means producer). Publisher pays for developing game. To do that, they must sign agreement. To sign it, developer must prepare work-schedule to make possible calculate costs. Without it, none of Publishers/producers will make a deal. Believe me, with some skills it is not too complicated to predict time of developing. Whole work you may just split into stages and evaluate those costs. It is also possible to over-estimate costs in case of expecting problems. With those information dev co. is able to paralelize work, hiring programmers etc. Without it it is impossible to do it effectively. Finally ISI doesn't do that from scratch. They have basis, that have skills. I'm sure they don't do that ad-hoc. Only exception is that ISI develops and publish things. So they not dependent on some signed deals.
Maybe you should continue this discussion somewhere else? I probably wouldn't even get started on cubemaps in my previous post if I knew my suggestions will be flooded with off-topic and probably never read by anyone from ISI in result.
K Szczec, I presume you have tried putting the cubemap in the track folder? I have experienced at times track textures overriding car textures. I have often wondered this but I have never got around to checking it. What will matter is what the name of the cubemap assigned to the particular car is. The standard is car_cube_dx9.dds, but sometimes cars will have a different name.
moreover car may have more cubemaps depending on material type. For example chrome rims will use other cubemap than car body etc.
That usually means a bug in car model - missing texture attachment. In that case car just takes whatever texture was last attached to a given texture unit when rendering something else (part of the scene, another car). I don't know that for sure - it's just an educated guess. Name doesn't matter - it's stored in .GMT file and rFactor will read exactly that texture. If it can't find it, then it will report an error and will not display the car ingame. Of course special materials like WCCARBODY, WCWINDOW, WCEXTRA, etc. will use skin textures, but that does not replace cubemaps, only base textures. Unfortunately that's how it is, but it shouldn't be. Cubemap should not be a part of material nor object. Cubemap is a representation of incoming light from surrounding world. No matter if it's plastic or metal - as long as surroundings are the same, cubemap is the same aswell. The only dfference is, some materials have rough surfaces, and will bounce light at various angles, which means reflection will be blurry, but it will still represent exactly the same environment. Of course if you want to make cubemap for fire extinguisher laying on the floor of a car, it will have different surroundings (car's interior) and therefore it can have different cubemap. But it's not material properties that decide what's on the cubemap - it's object's location. Simply put - if you are somewhere else, then you're surrounded by something else. I think using completely unrelated cubemaps on different materials comes from the fact, that modders don't make cubemaps themselves. If a cubemap is too sharp (too clear) for a given type of material, they don't try to make more blurry version of it, but simply look for some other cubemap. I'm betting many modders don't even know how to combine 6 images into cubemap. In programs like 3D studio you don't have to add any cubemap to have reflections. Same should be true for game engines - it should be engine's responsibility to provide a cubemap with various levels of blur and of course in floating-point color format.
What I mean is, if the modeller named the cube mycar_cube_dx9 then it wont work. But that is irrelevant now, I test it and now I know for sure it doesn't work. [ED] I'm betting most cubemap makers don't know how to combine 6 poly's to make a car. Sorry, but I couldn't help myself, you shouldn't presume things like this, there are a lot of very intelligent people in this modding community. Saying things like that offends people and is not necessary. http://www.cgtextures.com/content.php?action=tutorial&name=cubemaps
I think you misunderstood me. I didn't say many modders are unable to learn how to make cubemaps. I'm only saying many do not know how. And I'm saying 'many' not 'most'. How many mods have their own cubemaps? Usually nowadays people just take cubemaps by GSMF Alien & 6e66o. Probably because it's easy that way, but in many cases bacause making cubemaps is something that person didn't learn yet. Besides my point was that you don't need to know a thing about cubemaps to make a good 3D model in 3D Studio
Yeah, it's all good . Personally I like the K.I.S.S. approach, "Keep it simple stupid". I just use the default isi cubemaps for this exact reason, I don't see the point in making a custom cubemap if it will not reflect the actual environment. I think the only cubemap that would be relative to the actual environment is a cockpit cubemap. I have been experimenting with this for the 599 because the dash is polished carbon fibre and has a lot of reflection, it looks kinda weird being inside the car and it reflecting trees But looking at that cubemap in the gc textures website, I like the way it is just a horizon and a sky, that sort of cube would suit nearly every track. The only thing that I think can make a difference with rf1 and cubemaps is a plugin, maybe you might like to have a look into that? see if it is possible to make a plugin that will pick up custom cubemaps for each track and apply them to the car.
That's probably possible as a combination of rFactor plugin, a DirectX wrapper and a custom made-track and perhaps even a custom-made car. That doesn't sound like something I'm interested in doing It would be much better and much simplier if rFactor 2 engine could just provide cubemap. And it will. The thing is - will this cubemap be suitable for all kinds of materials or just the car body and windows? Even tyres should have cubemaps, but blurry. Look at these: You can clearly see horizon and sky reflected in these tyres. You can do that with cubemap, but you need a blurry one. So, if engine provides per-track or fully dynamic cubemap for car body, then it would be good if it would provide more blurry cubemaps for other materials. Best approach in my opinion is to have one extra cubemap with blur increasing with mipmap level and therefore my previous proposal.
