P-47 Progress Thread
- Thread starter Frosty
- Start date
. Gmax screenie:
Frosty
SOH-CM-2022
Now you have to do the underside, then the fuselage, and then.................
...
Haha, yeah, don't remind me
!I 'd like to get rid of a little stretching at the leading edge of the wing and then I can copy most of these rivets to the right wing. Part of the fuselage is already done but the underside of the wing is as much a pain in the * as the top side is. This is more time consuming than I imagined! But hey, the upside is that once these rivets are done, the real fun begins: bump mapping and weathering! That's much more appealing to me!
Pat Pattle
SOH-CM-2024
Hi Joost, 
Have just been catching up on this one, fantastic detail going into this, extremely impressive!!
Have just been catching up on this one, fantastic detail going into this, extremely impressive!!
Daiwilletti
Charter Member
Drooool . . . . I've been wondering, what with the crazy large bump map dds files, will I have to sell a kidney and fork out for a decent video card, to properly enjoy such a painstakingly carefully crafted model? There are so many tasty new models with 15 Mb bump map textures, not to mention Airfighter55's massive texture files for vehicles.
Can't wait for this bird
Can't wait for this bird
Frosty
SOH-CM-2022
Keep your kidneys where they serve best, I would say
:I have an old PC with a graphics card a friend gave to me: Intel i7 2,93GHz 4Gb RAM, originally Win7 Home x64 upgraded to Win10, Radeon HD5700 1024Mb. I get around 50-58 FPS in clear skies with this P-47 model and around 25-30 FPS over ACC airfields. Occasional stutter but nothing serious. I do use GameBooster to close as much background processes as possible before I start CFS3 and TrackIR.
The model texture files are not as big as Renatus' but the model is not finished yet. I am working with 4096x4096 textures, giving roughly 8Mb .dds files.
Daiwilletti
Charter Member
Absolutely no problem with you fab model having good sized textures Frosty! Absolutely a must for such a lovingly made model.
I guess I was thinking aloud about the cumulative effect of all the bump map textures of all the fab new models that are filling CFS3 skies recently. My vid card seems ok apart from a weird model cache overflow reported in the D3D log. It will be great if I can render them in all their glory.
I guess I was thinking aloud about the cumulative effect of all the bump map textures of all the fab new models that are filling CFS3 skies recently. My vid card seems ok apart from a weird model cache overflow reported in the D3D log. It will be great if I can render them in all their glory.
mongoose
SOH-CM-2023
Joost, I was just thinking about 4096 textures in bed last night
, as I thought I had read somewhere here that CFS3 would convert those back to 2048?? I seem to think it was something Andy or Dan might have mentioned???
MajorMagee
SOH-CM-2022
The mos file generator does not allow for large textures. This used to drive me crazy when I would upscale a texture and then it would still look as bad as ever, and I didn't know why. Then I discovered that it was the mos file that was derezzing the enhanced textures.
If you don't want to use a mos file then large textures are no problem. I've slowly gotten rid of my mos files over time as I upgraded each legacy aircraft's texture to higher resolution. For me, I'd rather have a high fidelity model most of the time, than seeing bullet hole decals appear on an aircraft that's seconds away from being destroyed anyway.
If you don't want to use a mos file then large textures are no problem. I've slowly gotten rid of my mos files over time as I upgraded each legacy aircraft's texture to higher resolution. For me, I'd rather have a high fidelity model most of the time, than seeing bullet hole decals appear on an aircraft that's seconds away from being destroyed anyway.
Frosty
SOH-CM-2022
Still busy unwrapping and texturing, so it's time for a (low res) gmax piccie of the engine/turbo/intercooler internals of the P-47 that are visible in CFS3 external view:
Gmax doesn't seem to be able to handle my large textures, so I had to downsize the texture setting. But I am having much fun playing with material values - and getting decent results in some places! Cowl flaps, oil cooler doors and intercooler waste gates are depicted in open position. BTW, the texturing isn't finished but for reference I already painted some parts.
Gmax doesn't seem to be able to handle my large textures, so I had to downsize the texture setting. But I am having much fun playing with material values - and getting decent results in some places! Cowl flaps, oil cooler doors and intercooler waste gates are depicted in open position. BTW, the texturing isn't finished but for reference I already painted some parts.
Attachments
Pat Pattle
SOH-CM-2024
Fantastic work there Joost!!
As the textured poly count goes up, so Gmax starts puffing in its 2gb memory space - I simply can’t display a full, textured model without crashing. The solution was to make named selection sets of different sections of the model and only display what I needed to work on. Of course, if you switch all textures off in the viewport, or use wireframe view, you can show the lot.
Frosty
SOH-CM-2022
From your tutorials I knew about selection sets but right now gmax can't even display a simple textured object at full resolution without crashing, lol. . I have to go to CFS3 to see the result of my work.
I wonder if the material set-up also influences the memory load; Currently I have created two big multi-materials (ca. 22 different material settings) for all external objects (excl. VC), instead of multiple smaller multi-materials. At the time this felt more 'efficient' than a long list of various material combinations but I think this also taxes the system. Not being that PC-savy, it feels like the debate whether loading a multitude of small textures is better for your FPS than a single, large texture. In the end I would expect both methods to give the same amount of Mb loaded, or am I wrong?
Whatever the outcome of such a debate, the multimaterials use the same two 4096 textures but with different material settings, of course. I am using multimaterials to get as 'PBR' as possible Yes, I know CFS3 isn't PBR compatible but I seem to get decent results playing with values derived from that way of designing.
Anyway, you can do much more with the material settings in gmax than I have done with my models so far. We tinker a lot with _r and _s textures etc. but using appropriate settings in gmax also contribute to a convincing model!
. I have to go to CFS3 to see the result of my work.I wonder if the material set-up also influences the memory load; Currently I have created two big multi-materials (ca. 22 different material settings) for all external objects (excl. VC), instead of multiple smaller multi-materials. At the time this felt more 'efficient' than a long list of various material combinations but I think this also taxes the system. Not being that PC-savy, it feels like the debate whether loading a multitude of small textures is better for your FPS than a single, large texture. In the end I would expect both methods to give the same amount of Mb loaded, or am I wrong?
Whatever the outcome of such a debate, the multimaterials use the same two 4096 textures but with different material settings, of course. I am using multimaterials to get as 'PBR' as possible Yes, I know CFS3 isn't PBR compatible but I seem to get decent results playing with values derived from that way of designing.
Anyway, you can do much more with the material settings in gmax than I have done with my models so far. We tinker a lot with _r and _s textures etc. but using appropriate settings in gmax also contribute to a convincing model!
Frosty
SOH-CM-2022
Now I am a bit confused: I went for a *_r.dds file with this model as I thought the stock bare metal P-47D-25 had one. I just checked and it turns out it has both a *_s.dds and a *_r.dds file. Yet the SDK states that you can't have both simultaneously! Both stock files do look quite similar. Now what?
Frosty
SOH-CM-2022
After a good night's rest I remembered why I choose the *_r.dds when I started this: Seeing both files in the stock P-47D-25 folder, I opened its .m3d with a hexeditor and found that the model uses the *_r.dds. My model also having a bare metal finish, I copied that choice. I don't know why there also is a *_s.dds included but it doesn't seem to be used by the model.
Is there a preference for either the *_r.dds or the *_s.dds and if so, could someone tell me why?
Is there a preference for either the *_r.dds or the *_s.dds and if so, could someone tell me why?
MajorMagee
SOH-CM-2022
The original intention was for r to map out the specular reflection patterns, and the s to determine the shadowing to simulate ambient occlusion. The naming convention is actually only relevant to help identify which is used for what.
AnKor's shaders take advantage of the r file's specular information to regulate the strength of the localized glossiness (great for highlighting chipped paint spots), but typically do their own shading through their self-shadowing routines.
The issue with using any sort of texture map to define the lighting qualities of a 3D object that moves through space like an airplane (versus trucks, buildings, trees, etc.) is that they are static, when the lighting is not. Paint in a dark to bright gradient along the top of a curved surface to emphasize the sun falling on it from above using an s file, and it will look wrong when the aircraft banks. Give the surface material a uniform brightness with AnKors shaders and they will automatically adjust the brightness gradient on the surface based on the relative direction of the sun.
AnKor's shaders also allow us to use normal maps to assist with the dynamic lighting in game. The intention here is to create the illusion of bumps using height difference information that changes the local direction vector of the light bouncing off an otherwise flat polygon surface. Again this is predetermined in a static texture map, so it may give erroneous results as the aircraft moves and turns in space, but if we're dealing with small features like panel lines and rivets the illusion works well enough most of the time.
AnKor's shaders take advantage of the r file's specular information to regulate the strength of the localized glossiness (great for highlighting chipped paint spots), but typically do their own shading through their self-shadowing routines.
The issue with using any sort of texture map to define the lighting qualities of a 3D object that moves through space like an airplane (versus trucks, buildings, trees, etc.) is that they are static, when the lighting is not. Paint in a dark to bright gradient along the top of a curved surface to emphasize the sun falling on it from above using an s file, and it will look wrong when the aircraft banks. Give the surface material a uniform brightness with AnKors shaders and they will automatically adjust the brightness gradient on the surface based on the relative direction of the sun.
AnKor's shaders also allow us to use normal maps to assist with the dynamic lighting in game. The intention here is to create the illusion of bumps using height difference information that changes the local direction vector of the light bouncing off an otherwise flat polygon surface. Again this is predetermined in a static texture map, so it may give erroneous results as the aircraft moves and turns in space, but if we're dealing with small features like panel lines and rivets the illusion works well enough most of the time.