Pat Pattle
SOH-CM-2024
The facility trees are in the buildings folder, they are just normal M3d's just like the hangars and huts etc.
Ankors new tool sounds very intriguing!
-
Guest Please check out the Help Wanted thread in Ickie's NewsHawks.
The future of the Outhouse depends on you!
Help Wanted
This Could Be Very Interesting - AnKor's Shaders
- Thread starter MajorMagee
- Start date
The facility trees are in the buildings folder, they are just normal M3d's just like the hangars and huts etc.
Ankors new tool sounds very intriguing!
Pat Pattle
SOH-CM-2024
How did you get the ripper to work with the 3d viewer please Stephen? I tried a number of times with no luck.
Pat Pattle
SOH-CM-2024
Doh! I tried everything but that! Thanks, all working now, just have to fiddle around with the Blender part as its not producing MCX readable files at the moment.
Clive,
yeah, I can only seem to open the ripped .obj files with Blender. Then border select the visible parts you want, inverse select the non-visible parts and delete. Now you can export as a 3ds file that Mcx will open. I find its easiest to rotate and scale the model in Mcx.
yeah, I can only seem to open the ripped .obj files with Blender. Then border select the visible parts you want, inverse select the non-visible parts and delete. Now you can export as a 3ds file that Mcx will open. I find its easiest to rotate and scale the model in Mcx.
Pat Pattle
SOH-CM-2024
Thanks Stephen! All sorted. To get it to work for me I had to delete the unnecessary bits and re-save as an .obj in Blender than open it in MCX 1.3 and then export to 3ds.
I'll have a go at some trees next.
Clive,
looks good! When I export a .obj from blender it seems to merge a bunch of the parts together which is a big problem on larger projects. I have not had that problem when exporting as .3ds. I still need to run that thru Mcx and export as the older style 3ds before importing into gmax.
looks good! When I export a .obj from blender it seems to merge a bunch of the parts together which is a big problem on larger projects. I have not had that problem when exporting as .3ds. I still need to run that thru Mcx and export as the older style 3ds before importing into gmax.
Daiwilletti
Charter Member
These last few posts about grabbing objects in m3d view and creating models is very interesting. They really deserve a thread of their won, I fear they will be lost in amongst the pages required for Ankor's shaders.
While I can't help with extracting tree models, I can say that if you list facility tree textures under [Foliage] in TextureMagic.ini they will use the same lighting as autogen trees.
As for merging facility models - it looks good, but I'm still working on improving it. I will likely release a "compatible" version to use with existing DX9 shaders or stock CFS3, but there's also going to be a much more efficient one for new WOTR shaders - it will use GPU instancing and thus will produce much smaller m3d files, also requiring less memory in game.
The problem with "compatible" version is that each tree model has to be copied as many times as it appears on facility, so it can easily reach 10 Mb file for less than a hundred of trees. While I am pleasantly surprised that both cfs3 and my DX9 shaders can handle this, it is obviously not the way to go.
Instancing version will store a single copy of tree model and just 64 bytes (bytes!) per instance. So a hundred of copies will add just about 6 Kb of overhead.
As for merging facility models - it looks good, but I'm still working on improving it. I will likely release a "compatible" version to use with existing DX9 shaders or stock CFS3, but there's also going to be a much more efficient one for new WOTR shaders - it will use GPU instancing and thus will produce much smaller m3d files, also requiring less memory in game.
The problem with "compatible" version is that each tree model has to be copied as many times as it appears on facility, so it can easily reach 10 Mb file for less than a hundred of trees. While I am pleasantly surprised that both cfs3 and my DX9 shaders can handle this, it is obviously not the way to go.
Instancing version will store a single copy of tree model and just 64 bytes (bytes!) per instance. So a hundred of copies will add just about 6 Kb of overhead.
NachtPiloten
Kurier auf Stube...pauke!
Question
What is the purpose of putting the search_light.dds entry in the texture...ini? The reason I ask is that is not the dds name of the textures for the search_lights we have in game, I will add those in the same location as the above, but just curious as to why this is done.
What is the purpose of putting the search_light.dds entry in the texture...ini? The reason I ask is that is not the dds name of the textures for the search_lights we have in game, I will add those in the same location as the above, but just curious as to why this is done.
NachtPiloten
Kurier auf Stube...pauke!
Lights
Tks, - we have had searchlights in CFS3 for many years, just trying to take advantage of the new shaders (many thanks). The WOFF ones are copies of the original ground crew ones done way back in 2004 or so. Thanks again for all your great efforts!
Tks, - we have had searchlights in CFS3 for many years, just trying to take advantage of the new shaders (many thanks). The WOFF ones are copies of the original ground crew ones done way back in 2004 or so. Thanks again for all your great efforts!
MajorMagee
SOH-CM-2022
Reticle effect information for P-40B/C Tomahawk
<Effect Type="Track" EffectName="US_AAF_N6a_gunsight" PosX="-0.005" PosZ="-0.80" PosY="0.7525" Pitch="90.5" MinVel="-999999" MaxVel="999999"/>
<Effect Type="Track" EffectName="US_AAF_N6a_gunsight" PosX="-0.005" PosZ="-0.80" PosY="0.7525" Pitch="90.5" MinVel="-999999" MaxVel="999999"/>
As you may know, I'm working on new shaders for WOTR and since some will likely want to use them for CFS3 I wanted to mention one "breaking" change in new shaders.
When CFS3 renders Virtual Cockpit view it removes a part of external model related to cockpit and inserts more detailed VC model instead. Additionally VC model is rendered in a way that it is overlaid on top of anything external, regardless of actual Z values.
The latter was required because Z buffer at the time was unable to precisely represent a range of distances from millimeters in cockpit to a more than a hundred of kms outside. Putting everything into a single "scene" would cause bad z-fighting (flickering of closely placed objects). That's why CFS3 first rendered external scene first and then cleared Z buffer and adjusted Z range to render the cockpit. This worked, but caused visual issues even in stock DX8 mode, but was especially bad for my DX9 shaders where I had to invent a tricky rendering sequence to reduce overdraw (so that I was able to render cockpit first and only render those external parts or terrain which are not obscured). It was really painful to handle and still had issues. For example, [CockpitSprite] section in TextureMagic was required to let certain sprites be rendered inside the cockpit instead of being obscured.
Current hardware (or rather a simple and smart trick invented some years ago) allow using a very precise Z buffer practically at the same cost as a conventional one. It allows discerning Z values at precision no worse than 0.005 m (half a millimeter!) within 150 km visibility range! Basically you can put everything into one scene and don't worry about z-fighting. Well, not that simple - at those ranges other issues tend to appear, but you see the point
So, new shaders will use this new Z buffer and will render everything together.
But what is the downside?
Well, it is not actually a downside, it can be used to advantage, but it breaks that part of old renderer where "cockpit is overlaid on top of everything else". CFS3 will still remove the cockpit part of external model, but if something is not removed it may stick through VC model into the cockpit.
Good news is that it doesn't affect any stock CFS3 aircrafts, and recently released FW 190 and Me 163 are unaffected too (but these are only recently released models I have to test). I understand there are hundreds of 3rd party models, but if a modeller was careful enough to mark all required external parts to be removed from cockpit and didn't leave any "shared" surfaces everything should be ok.
One 3rd party model that works badly is Mig 15 (don't remember which one) because for some reason VC model is a bit wider than the aircraft itself and I can see fuselage sides inside the cockpit.
Certain WOFF aircrafts tend to have issues. Some has low-res external view gauges, headrests or other nearby parts not removed in VC view. Sometimes it is an oversight, sometimes they had to do this to make WWI biplane open cockpits work correctly. Most of them are ok though.
The point of this post is to let you know that some old aircrafts may have issues with new shaders, and if you are making new aircrafts try not to rely on "cockpit hides everything" behavior and properly mark external surfaces to be removed in VC view.
When CFS3 renders Virtual Cockpit view it removes a part of external model related to cockpit and inserts more detailed VC model instead. Additionally VC model is rendered in a way that it is overlaid on top of anything external, regardless of actual Z values.
The latter was required because Z buffer at the time was unable to precisely represent a range of distances from millimeters in cockpit to a more than a hundred of kms outside. Putting everything into a single "scene" would cause bad z-fighting (flickering of closely placed objects). That's why CFS3 first rendered external scene first and then cleared Z buffer and adjusted Z range to render the cockpit. This worked, but caused visual issues even in stock DX8 mode, but was especially bad for my DX9 shaders where I had to invent a tricky rendering sequence to reduce overdraw (so that I was able to render cockpit first and only render those external parts or terrain which are not obscured). It was really painful to handle and still had issues. For example, [CockpitSprite] section in TextureMagic was required to let certain sprites be rendered inside the cockpit instead of being obscured.
Current hardware (or rather a simple and smart trick invented some years ago) allow using a very precise Z buffer practically at the same cost as a conventional one. It allows discerning Z values at precision no worse than 0.005 m (half a millimeter!) within 150 km visibility range! Basically you can put everything into one scene and don't worry about z-fighting. Well, not that simple - at those ranges other issues tend to appear, but you see the point
So, new shaders will use this new Z buffer and will render everything together.
But what is the downside?
Well, it is not actually a downside, it can be used to advantage, but it breaks that part of old renderer where "cockpit is overlaid on top of everything else". CFS3 will still remove the cockpit part of external model, but if something is not removed it may stick through VC model into the cockpit.
Good news is that it doesn't affect any stock CFS3 aircrafts, and recently released FW 190 and Me 163 are unaffected too (but these are only recently released models I have to test). I understand there are hundreds of 3rd party models, but if a modeller was careful enough to mark all required external parts to be removed from cockpit and didn't leave any "shared" surfaces everything should be ok.
One 3rd party model that works badly is Mig 15 (don't remember which one) because for some reason VC model is a bit wider than the aircraft itself and I can see fuselage sides inside the cockpit.
Certain WOFF aircrafts tend to have issues. Some has low-res external view gauges, headrests or other nearby parts not removed in VC view. Sometimes it is an oversight, sometimes they had to do this to make WWI biplane open cockpits work correctly. Most of them are ok though.
The point of this post is to let you know that some old aircrafts may have issues with new shaders, and if you are making new aircrafts try not to rely on "cockpit hides everything" behavior and properly mark external surfaces to be removed in VC view.
MajorMagee
SOH-CM-2022
The Mig-15bis was an example where a cockpit was borrowed from another model to shorten the development cycle. Something similar was done for a number of ai only models that we've made flyable as beta versions.
Will the new rendering approach bring any particular performance benefits or new capabilities to the game?
Will the new rendering approach bring any particular performance benefits or new capabilities to the game?
New approach should not be slower than the original one, I doubt it is faster, but it is well supported by modern hardware.
It makes code simpler.
It will allow me to add some new effects which weren't previously possible because Z buffer values were inconsistent.
It removes Z-fighting - i.e. in WOFF it is sometimes visible how distant facility buildings flicker if you look from high altitude, shouldn't be the case anymore.
It could make modelling easier if you intentionally want to have external parts visible in VC. For example some WW1 aircrafts have that small propeller attached to a strut which pressurizes the fuel tank, but CFS3 doesn't allow blurred prop in VC model and OBD guys had to go through hoops to make external model propeller visible in VC mode.
Here is how it looks in Mig 15.
Oh, and I've just figured out that my Mig 15 is not "Mig15 bis" you are referring to, somehow I missed that there's a new model you made with BorekS. My one is an ancient model from 2003 and I don't even remember where I got it. Need to try the new one
It makes code simpler.
It will allow me to add some new effects which weren't previously possible because Z buffer values were inconsistent.
It removes Z-fighting - i.e. in WOFF it is sometimes visible how distant facility buildings flicker if you look from high altitude, shouldn't be the case anymore.
It could make modelling easier if you intentionally want to have external parts visible in VC. For example some WW1 aircrafts have that small propeller attached to a strut which pressurizes the fuel tank, but CFS3 doesn't allow blurred prop in VC model and OBD guys had to go through hoops to make external model propeller visible in VC mode.
Here is how it looks in Mig 15.
Oh, and I've just figured out that my Mig 15 is not "Mig15 bis" you are referring to, somehow I missed that there's a new model you made with BorekS. My one is an ancient model from 2003 and I don't even remember where I got it. Need to try the new one
Attachments
Last edited:
gecko
Charter Member
Ah, I see some new possibilities with cockpit animations with this, since animations that are only available in the external model can now be used inside the cockpit.
I'm curious if there is a way ensure that models being worked on currently don't have conflicts between the external and VC?
I'm curious if there is a way ensure that models being worked on currently don't have conflicts between the external and VC?
I plan to make a preview build sometime soon, but only for development use, not for public.
PS: 0.005 m is actually 5mm, not 0.5mm as I said before, but that's the worst case which happens at distances above 50km
The best case is much more precise. And cockpit distance is the best case.
PS: 0.005 m is actually 5mm, not 0.5mm as I said before, but that's the worst case which happens at distances above 50km
The best case is much more precise. And cockpit distance is the best case.