FSDT New ground technique

[BrBlazer]

Hey all,

What do you guys make of this:

http://www.fsdreamteam.com/forum/index.php?topic=3037.0

I wonder how they managed full 100% native FSX, without any flickers as by what I read they are not using the fs2002 poly hack.

 

[BASys]

Hi Folks

BrBlazer -
Not in any way decrying achievement.

Seen previously,
it's too short and limited a scoped video
to pronounce any worthwhile judgement.

Panning stutter/stall, infers major FPS impact,
albeit from a declared old video.

Bumpmaps are definitely over emphasised.

Using ground polys != using an fs2002 poly hack.

Maybe a translation matter,
but statement -

due to the use of FS8 legacy code in FSX,

should probably read -

due to our use of FS8 legacy code in FSX,

Only surprising aspect is
HowTo/Recipe was supplied to devs by MS in 2006.

HTH
ATB
Paul

 

[arno]

Hi,

If they are using bump maps, etc, then it will not be FS2002 style techniques indeed. So most likely FSX MDL files then, unless they found something completely new.

 

[PakMac]

Here's an interesting question on their forum regarding seasonal textures.

It looks like they are using FSX MDL files for their ground textures, and Simconnect for texture switching.

David

 

[hek293]

But there must be loads of texture flickering on the gpolys if they are indeed .MDL no?

They also seem to have the aircraft shadows casted on these ground textures which is not possible with .MDL?

 

[PakMac]

If you attach a platform to your model, then shadows will show.

Flickering can be cured by raising it of of the ground by 0.01 in gmax.

 

[hek293]

could u have layers of gpolys with .MDL format as you can have with the FS2002 (asm twk) method though?

 

[arno]

Hi,

No, layers are not supported. But you could give them an offset in height of course.

At the moment I am experimenting with using FSX MDL files for ground polygons. It seems you get the shadows on it even without using a platform so that is good news.

 

[hek293]

That's nice.. but I was always getting my aircraft sinking into the ground polys when they were made as .MDL

 

[arno]

Hi,

At the moment I do not have sunken wheels (yet), but I am still experimenting .

 

[virtuali]

Panning stutter/stall, infers major FPS impact, albeit from a declared old video.

The stutters are mostly due to Fraps CPU and GPU utilization, and there's no "major FPS impact" at all, because what FPS are eventuallty lost because of the more complex shaders that slower than the basic ones, are gained back because FSX native code executes faster than FS8 code and the two roughly even out. With recent video cards, the impact of having more complex shaders to run, becomes less of an issue.

Bumpmaps are definitely over emphasised.

As already explained on our forum: it was made on purpose, because otherwise the effect would have been lost due to video compression and low resolution, since H.264 codec used for video at the low bitrates used by Youtube, tend to reduce the smaller details.

In any case, the video is several months old, the scenery looks way better now, that was just a proof of concept video, it's obvious that, once we can do bump mapping, specular highlights and reflections, the amount of the effect can then be easily tuned.

Maybe a translation matter, but statement -

due to the use of FS8 legacy code in FSX,

should probably read
due to our use of FS8 legacy code in FSX,

The statement is correct as written. The usage of FS8 ground polygons forces everyone (not just "us" ) to several compromises and limitations, the most obvious one being the inability to use shader materials (unless you know a way to have bump+specular+reflection with FS8 polygons), but there are many others as well.

I confirm all ground polygons made with this method are created with the FSX SDK, which means they are in the MDLX format. Their display is managed by our Addon Manager module which is treating them as a special case, and they are not contained in a .BGL file.

 

[BASys]

Hi Folks

Umberto -
Again, not in any way decrying your achievements.

I could have expressed myself better,
it was late and after a few beers.

I fully appreciate that its an old video,
and doesn't reflect the current state of your implementation.

Bearing the above in mind -

I was solely commenting on the video as shown
and your supporting text in that FSDT thread.

Panning stutter/stall, infers major FPS impact,
albeit from a declared old video.

The point I was trying to make -

Other FRAPS videos successfully show panning
with multiple aircraft performing highly processor-intensive manouvers,
in wide camerashots, which also display scenery, clouds, etc.,
in a fluid manner, with minimal/no stutter/stall.

Whereas in your video,
of a stationary aircraft,
in a tight camerashot,
witout those other FPS impacting aspects,
theres obvious stutter/stall.

Whilst it shows the "basic technology",
it's not doing your achievement justice.

Bumpmaps are definitely over emphasised.

As already explained on our forum:
it was made on purpose,

I can't find that reference,
but I do understand the reason for their emphasis.

This is an entirely new ground rendering method,
which hasn't been used by anyone else before,
and allows for much better graphic quality,
without any of the compromises we had to do in the past,
due to the use of FS8 legacy code in FSX,
to create fully custom ground.

Again, maybe a translation matter -

Above infers that -
- FSX uses FS8 legacy code, (for custom ground),
and
- FSX is faulty WRT supporting that FS8 legacy code.

For clarity, (of others reading),
AIUI,
the old ground-poly method
was not "FS8 legacy code".

It was a '3rd party ASM hack'
which was never supported by MS.

i.e.
It was entirely 'your choice' in the past
attempting to implement a 3rd party unsupported hack.

Bottom line -
Its not the fault of FSX
that the 3rd party unsupported hack
did not work in FSX.

Hence -

Maybe a translation matter,
but statement -

due to the use of FS8 legacy code in FSX,

should probably read -

due to our use of FS8 legacy code in FSX,

Hope this sufficiently clarifies matters.



re: New FSX groundpolys

Their display is managed by our Addon Manager module
which is treating them as a special case,
and they are not contained in a .BGL file.

Did Adam's HowTo/Recipe not work ?

Interested to hear pros/cons of both methods
that led to your choice of implementation.



Is the following related to above choice ?

THANKS to the Addon Manager,
that allows several optimizations
that FSX BGL-only sceneries can't use anymore
(like LOD, selective loading with realtime checks for distance, viewpoint and altituide)

Intrigued by your FSX BGL-only LOD comment.
Could you explain a little please ?



Really looking forward to seeing
an updated video of your completed implementation.



Many thanks.

ATB
Paul

 

[virtuali]

Whereas in your video, of a stationary aircraft,
in a tight camerashot,witout those other FPS impacting aspects, theres obvious stutter/stall.

The video doesn't try to represent anything related to performances, it was made just as a quick test, and the fact that other videos made with fraps runs better, doesn't automatically proves there's a performance loss due to THIS method but, quite simply, those other videos were just made on a better system or with a better configured fraps, or whatever.

For clarity, (of others reading), AIUI, the old ground-poly method was not "FS8 legacy code". It was a '3rd party ASM hack' which was never supported by MS.

The old ground-poly method was BOTH FS8 legacy code and was also an ASM hack on top of it. Even without the hack, it was still FS8 legacy code.

It was entirely 'your choice' in the past attempting to implement a 3rd party unsupported hack.

The "hack" doesn't have anything to do with this, but rather the ability to use FSX materials, that's the point of the whole thing! This is what we are refering to, mainly, when we said there are limitations by using FS8 code in FSX.

Its not the fault of FSX that the 3rd party unsupported hack did not work in FSX.

Even standard and supported FS8 code (which IS legacy in any case), the full FSX graphic potential can't be exploited for ground layers, because of the lack of shaders when running the FS8 code.

Interested to hear pros/cons of both methods
that led to your choice of implementation.

by moving some of the visual effects to Shaders, we can reduce the usage of multiple layers of several polygons stacked together to achieve a certain visual effect.

Also, we noticed a degeneration in the usage of ultra-hi resolution photo images in other sceneries, trying to get good ground detail, without having to resort to FS8 code.

But this is a lost battle, since even 7cm/pixel is still not sharp enough when very close, and it would clobber the graphic memory with textures. AND, it will STILL look "flat", because without bump/specular/reflection maps, the textures will not react dynamically to the changing light angle.

With a shader, the texture resolution doesn't need to be so high, because the overally detail impression is coming also from the bump mapping, and it's more effective, because it changes with the viewing angle so, pavements cracks looks like they should.

Intrigued by your FSX BGL-only LOD comment. Could you explain a little please ?

It's actually backwards: it isn't a "BGL-only" thing, it's a "BGL-less" thing because, these ground polygons are not compiled in a .BGL file.

However, the LOD thing means: IF we'll eventually notice that, the use of Shaders for ground polygons would result in a noticeable performance loss (which we don't expect on fairly recent video cards and it might simply balance out with the fact that we are running less polygons and we are running a faster FSX code) we might even dynamically switch off shaders when not needed, as if after a certain distance or altitude or simply making an in-game menu to turn it off.

But we need to verify this when the scenery is done. One shouldn't forget this is not a bush airfield, it's KDFW, which has an area compared to KORD + KJFK PUT TOGETHER!

Really looking forward to seeing an updated video of your completed implementation.

There might not be necessary, since we don't usually use carefully made videos to promote our sceneries, since they all come in Trial versions so, nothing better than that. That's why we aren't that good at making convincing videos...we don't need them

 

[Roland81]

Is this really worth it? I know that the folks at FSDT had to install a special .dll file so that the flikering and such (which FSX SDK can't stop) would work out, basically a hack? all the effort and work in the end did it look better?

 

[Timmo]

I guess the question for me is, can this method be used by 'anyone' or does it require additional components (such as tools or dlls) created by FSDT?

 

[arno]

I am experimenting using it without any additional components. It is not perfect yet, but looks promising.

I started to look into it when I realised there is an error in the accuracy of FS2002 style polygons in FSX.

 

[GrandSurf]

@Arno an all other , up to which result have you come with your experiments?

Is there then with the "normal" FSXA-SDK a way these Groundpolys to provide like FSDT it does? If it functioned, so perhaps: export the Poly from 3dsmax with the FSX Material to .x, convert it to .mdl/.xml and with Library Creator XML in library and when in the FSX?

Instead of the 2002GP i would rather like to use the complete FSXA-SDK for Scenerys.