This Could Be Very Interesting - AnKor's Shaders - Page 29
Page 29 of 32 FirstFirst ... 19212223242526272829303132 LastLast
Results 701 to 725 of 800

Thread: This Could Be Very Interesting - AnKor's Shaders

  1. #701
    SOH-CM-2024 Pat Pattle's Avatar
    Join Date
    Jun 2005
    Location
    Newton Abbot, Devon. Dear old Blighty
    Age
    60
    Posts
    2,904
    Blog Entries
    1
    One thing that would be beyond greatness would be having facility trees that look like the autogen trees. Uniform looks, you know. Anyone have any idea where the models are located?
    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!
    CFS3 Battle of Britain Website: https://cfs3bob.wixsite.com/cfs3-bob
    CFS3 ACC Member & ETO Expansion Group

  2. #702
    One thing that would be beyond greatness would be having facility trees that look like the autogen trees. Uniform looks, you know. Anyone have any idea where the models are located?
    If you don't find them, you could fly around and 3d-rip the autogen trees and convert them to facility usable objects. Does require the use of gmax though so maybe someone has a better answer.



  3. #703
    SOH-CM-2024 Pat Pattle's Avatar
    Join Date
    Jun 2005
    Location
    Newton Abbot, Devon. Dear old Blighty
    Age
    60
    Posts
    2,904
    Blog Entries
    1
    How did you get the ripper to work with the 3d viewer please Stephen? I tried a number of times with no luck.
    CFS3 Battle of Britain Website: https://cfs3bob.wixsite.com/cfs3-bob
    CFS3 ACC Member & ETO Expansion Group

  4. #704
    Clive,
    that 3d viewer screenie was a tree that has allready been converted to m3d .

    to launch cfs3 3d viewer from 3dripper make sure you fill out the command line.


  5. #705
    SOH-CM-2024 Pat Pattle's Avatar
    Join Date
    Jun 2005
    Location
    Newton Abbot, Devon. Dear old Blighty
    Age
    60
    Posts
    2,904
    Blog Entries
    1
    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.
    CFS3 Battle of Britain Website: https://cfs3bob.wixsite.com/cfs3-bob
    CFS3 ACC Member & ETO Expansion Group

  6. #706
    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.

  7. #707
    SOH-CM-2024 Pat Pattle's Avatar
    Join Date
    Jun 2005
    Location
    Newton Abbot, Devon. Dear old Blighty
    Age
    60
    Posts
    2,904
    Blog Entries
    1
    Quote Originally Posted by sdsbolt View Post
    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.
    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.

    CFS3 Battle of Britain Website: https://cfs3bob.wixsite.com/cfs3-bob
    CFS3 ACC Member & ETO Expansion Group

  8. #708
    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.

  9. #709
    SOH-CM-2020
    Join Date
    Jun 2005
    Location
    Aotearoa, New Zealand
    Age
    63
    Posts
    2,896

    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.

  10. #710
    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.

  11. #711
    Sounds like you've been making some real headway with the WOTR shaders, looking forward to seeing them in action someday!

  12. #712
    Kurier auf Stube...pauke! NachtPiloten's Avatar
    Join Date
    Jun 2005
    Location
    Leland, North Carolina, USA
    Age
    66
    Posts
    1,996

    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.

  13. #713
    search_light.dds is used by WOFF searchlights
    I think someone (gecko? ) was trying to make similar searchlights for cfs3, but I don't know if it worked.

  14. #714
    Kurier auf Stube...pauke! NachtPiloten's Avatar
    Join Date
    Jun 2005
    Location
    Leland, North Carolina, USA
    Age
    66
    Posts
    1,996

    Icon23 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!

  15. #715
    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"/>
    US Army, Major, Ret.

    Service To The Line,
    On The Line,
    On Time

    US Army Ordnance Corps.

  16. #716
    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.

  17. #717
    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?
    US Army, Major, Ret.

    Service To The Line,
    On The Line,
    On Time

    US Army Ordnance Corps.

  18. #718
    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
    Attached Thumbnails Attached Thumbnails mig15.jpg  
    Last edited by AnKor; March 28th, 2018 at 06:11. Reason: added screenshot

  19. #719
    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?

  20. #720
    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.

  21. #721
    Ankor,

    Thank you for the advance notice on the new shaders. Sounds like it will allow us to add a few new animations at the very least.

    Will fog and smoke effects look the same in front of external parts as they do vc parts?

    Steve

  22. #722
    Fog, smoke and rain is a problem I'm still thinking about.
    There are some models which have VC parts placed as if they were external. For example Ground Crew's BF110 has gauges on engines.

    Currently these outside parts appear through fog. My new code will allow to fog them properly.
    However there's a reverse side of this: you wouldn't want to see smoke or rain inside closed cockpits, this could be especially bad for large bombers.

    I think I will make cockpit obscure rain effect as it always did because there's nothing else I can do.
    In-cloud fog overlay will likely go away and will be completely reworked.
    However I haven't decided yet what to do with smoke from gunfire. My current idea is to do additional rendering pass for cockpit to get Z values of its opaque parts and cockpit glass (normally semi-transparent objects don't write Z values) and then use these values to block sprites. This adds some overhead, but it should be relatively small.

  23. #723
    Here's an exciting new effect I sort of backed into this evening.

    I always noticed that the fx_N_gtrail wing tip vortex effect looked okay from the outside, but from inside the cockpit, the alpha transparency wasn't working and you saw a solid stripe instead of a vapor trail.

    After trying a number of fixes I discovered that referencing a different texture file resolved the issue. tr_condenstrail_basis2.dds that I provided with AnKor's Shaders was a perfect looking candidate, but when I tried it there seemed to be a new problem with it not always appearing when it should have. These effects have traditionally been implemented as speed dependent, but even expanding the speed range didn't fix the problem.

    This evening it dawned on me that tr_condenstrail_basis2.dds was being suppressed because it was listed in texturemagic.ini as [HighAltSprite] and would only appear at high altitude like all good contrails should. So I created a copy of the file with a different name called tr_condenstrail_basis3.dds and then it would show up properly whenever the speed range requirement was being met.

    That got me to thinking, that like contrails the wing tip vortex effect should really have been altitude dependent with it being limited to the thick humid air near the ground. AnKor's effect is set up so that the contrail effect becomes progressively more visible as you go above the threshold altitude, and then is 100% for everything above that. What I discovered just now was that you could trick it into doing the same thing to limit it to lower altitudes, getting progressively more visible as you descended, by adding this line to the [HighAltSprite] section of texturemagic.ini

    tr_condenstrail_basis3.dds= 2500|-1500

    This barely starts the effect at 8,200 ft, and it gets progressively more dense until it has 100% visibility below 3,300 ft.

    I've seen exactly this effect on commercial airliners during the summer as we've made our landing approach. It's barely visible as you initially break below the cloud base, and gets brighter as you continue to descend, disappearing as the speed drops after touchdown.

    With this ability you no longer have to restrict the gtrail effect to a narrow band of speeds to make it seem realistic. You could edit the aircraft xdp files to widen the speed range to cover more of the typical approach and landing speeds, and let the altitude control prevent it from showing up at combat altitudes.

    Editing the altitude value ranges in the texturemagic.ini would be needed to adjust for winter versus summer humidity levels to be completely accurate, but that's not an absolute requirement to use this.

    The entry in the effects.xml now looks like

    <fx_N_gtrail ClassName="GroupEffect" Effect0="N_track_contrail_s"/>
    <N_track_contrail_s ClassName="TrackEffect" FlatTrack="0" Lifetime="0" InitialDelay="0" ParticleLifetime="0.15" FadeInTime="0.02" FadeOutTime="0.12" PosX="0" PosY="0" PosZ="0" CountSegments="5" SegmentLength="2" Width="0.25" WidthGrow="1.2" InitialAlpha="0.00" InitialColor="250 250 255" Alpha="0.55" Color="250 250 255" FinalAlpha="0.00" FinalColor="250 250 255" BlendMode="QuadSprite" Texture="tr_condenstrail_basis3.dds" ZBias=".03"/>

    versus the original

    <fx_N_gtrail ClassName="GroupEffect" Effect0="N_track_contrail_s"/>
    <N_track_contrail_s ClassName="TrackEffect" FlatTrack="0" Lifetime="0" InitialDelay="0" ParticleLifetime="0.15" FadeInTime="0.02" FadeOutTime="0.12" PosX="0" PosY="0" PosZ="0" CountSegments="5" SegmentLength="2" Width="0.1" WidthGrow="1.2" InitialAlpha=".00" InitialColor="250 250 255" Alpha=".55" Color="250 250 255" FinalAlpha=".00" FinalColor="250 250 255" BlendMode="QuadSprite" Texture="tr_smoke_6.dds" ZBias=".03"/>

    *** Be careful not to end up with multiple copies of fx_N_gtrail as you edit effects.xml ***
    Last edited by MajorMagee; April 12th, 2018 at 17:11.
    US Army, Major, Ret.

    Service To The Line,
    On The Line,
    On Time

    US Army Ordnance Corps.

  24. #724
    Nice find! It is always interesting to see how people find unintended features in my code

    Meanwhile I did some background work for DX11 shaders and found how cfs3 checks velocity limits for track effects. This allowed me to plug additional conditions into that code. So far this just means that I can define contrails by effect's name instead of texture name and can avoid emitting them at all instead of just hiding them at rendering level.
    This could potentially allow more complex conditions for enabling/disabling effects, but I haven't thought about it much and not sure what is possible and what is not. Are there any interesting effects which require additional conditions?

    Unfortunately keeping contrails when aircraft is out of view is still impossible.

  25. #725
    Quote Originally Posted by MajorMagee View Post
    Here's an exciting new effect I sort of backed into this evening.
    You're a certifiable genius!

    I've been going mad trying to figure out how to get my helo dust effect appear at the right altitude and speed. This solves it perfectly!

    One minor thing: It is ineffective on airbases/land a couple hundred feet above sea level.


Similar Threads

  1. CH-37 :This would be interesting in FSX
    By Navy Chief in forum FSX General Discussion
    Replies: 11
    Last Post: October 23rd, 2014, 13:34
  2. Interesting Plane... Very interesting :)..
    By warchild in forum FSX General Discussion
    Replies: 8
    Last Post: May 29th, 2011, 17:24
  3. This looks interesting
    By gigabyte in forum Ickie's NewsHawks
    Replies: 2
    Last Post: April 25th, 2011, 12:55
  4. Interesting!
    By Tako_Kichi in forum Racer's Paddock
    Replies: 0
    Last Post: January 7th, 2009, 13:56

Members who have read this thread: 100

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •