Did you even read my post?

Yes it takes the cameras position and uses the x and z coords from it.
Yes it can be configured to use any vector, even the cameras point-at vector.

But, that isnt much more optimal than using the current X and Z of the cam pos, since now, the most detail is where the camera is closest to terrian, quite a sensible assumption, doesnt always work best.

But your proposed solution of using the point vector doesnt take into account when the cam is not pointing at the terrain, or the vector is close to parallel with the ground.

http://github.com/spring/spring/blob/42b688e2a0e531765479a57623b22ac051071e99/rts/Map/SMF/BFGroundDrawer.cpp



This defines the point of highest lod. Change->test->enjoy!

Ah. You're correct, I didn't worry about whether we were pointed at the ground at all.

I guess I assumed that if we didn't have a collision with the ground at any corner of the screen from the frustrum, we'd just not bother with a LOD at all that rendering pass.

But it's essential that we calculate the LOD based not on the X,Z of the camera, but on the nearest valid intercept. Otherwise we're generating a lot of terrain outside the frustrum at a higher LOD than it should be. Hence my complaint from the start.

That's why using the camera's position is a problem. I can see why you thought that might help a bit, but really it's not going to work correctly. 99% of the time, in a practical game, the camera's facing down. If we're in FPS mode, or if we've scrolled so that the center of the POV is no longer intercepting the ground... then we might need to get the LOD from an intercept based on one of the corners of the frustrum. Should be pretty easy to add that logic.

If no intercept-->get intercepts from camera position to worldspace based on corners of POV--> if no intercept, no LOD, if intercept, use closest distance to determine LOD.

That means up to 5 vector-interception tests with the groundplane per pass, but that's not too terrible. Especially if, as I requested, we look at not generating the vertexes every single frame, but instead space it out to 5 frames or so. This could result in a very large speed improvement for both SMF and SM3, and a considerable improvement on overall CPU load, while making it possible to finally view maps at somewhere close to perfect detail.

So this is what it feels like to be Argh'd. Yall got quite some patience, devs

Your change would result in using LODs when the camera's facing straight up.

That's why I'm saying to generate intercepts from the camera to the ground plane on all four corners, if the center doesn't result in an intercept. It's far cheaper to run the intercepts than to draw a bunch of geometry we cannot see.

At any rate, meh... improvement is improvement, and I will test it and see if it results in any practical changes.

And yes, since I know you're going to point this out, there should be an exception, if the camera is less than Y from the nearest ground.

Generate an intercept from some distance above the camera to the ground along the Z axis, and use that to generate a LOD that's mainly in front of the camera, where it belongs. That'll take care of low-flying behavior and FPS mode.

Yeah the installer delivered all the files needed and yes Urban now runs fine without that flickering. However it seems the fix has broken something:

On Urban the radar has become a "transparent" box showing nothing but the icons and the outline and when pressing F2 or F4 for the respective special views I just get an entirely grey map - I'd say the map becomes invisible and you just see the distance fog. All of this works fine on Narrow Passage...

The transparent box is because urban does not have a minimap image, whereas NP does.

Yes. Sorry, Urban was never intended to be anything but a rough technical test.

Should now be fixed too, that was actually an unrelated problem.

Indeed - works just fine now. Just keep working on the other problems & shortcomings of this format to make quite some people happy...

sm3 should e a easy fix for modern hardware, buggy/outdated hardware cn be left with supporting hosting regular maps. sm3 has really to come, it will bring a new visual verbosity to the game and doubling framerate!

oh how i miss thos test games from some 6 months ago where metal heck ran over 100% faster and had some complere new gfx goodies on top of that...

I will personally donate 20Ôé¼ by paypal for the mn making sm3 the defacto map format for spring. THIS IS A PROMISE

pm. me with the plan, and as soon i fonfirm the functionality ingame the money is yours.

A cookie for whoever completes SM3, cookie delivered upon the hearing of forum rapturous applause

I will seriously bake, ice and post a batch of Afghans for anyone seriously involved in the completion/fixing of sm3.

You can start by reporting which bugs still need attention.



Could you post a screenshot of this?

Kloot, you wil be a rich man afterwards.

Well I found out that this only occurs when you have shadows enabled. Without shadows things are fine (except for one edge of the terraformed section still having the original ground texture but I don't know if that's a shortcoming of the gadget):



With shadows on things look like this though:



On the right of this picture you also see an area which I "re-flatted" so it has to be a problem with the texture and not some strange shadowing...


Well you can add in 20 Ôé¼ from me too once I get a paypal account up and running (wanted to buy some tutorials anyway which needed paypal)...

ExtraTexture doesn't work for me, so it seems AlphaTest is enabled and it writes to the alpha channel - alphatest shouldn't be enabled during ground drawing!. Also there seems to be a backbuffer problem so I can see parts of the extratexture when I enable it, but it gets overriden when i move the camera.

Shadows doesn't work at all for me.

Cheers, that should no longer happen for any ground decals. (If you want to test, be sure to update springcontent.sdz too.)




It isn't, nothing in the SM3 code enables alpha testing.



In current master? There was a problem with FBO binding/unbinding up until a few days ago, cannot reproduce it anymore though.

I did some tests, and the shadowmap is not being built from the correct POV. This explains why it "shifts" and occasionally "floats".

See this article about how this problem can be corrected. Includes all relevant source.

http://fabiensanglard.net/shadowmapping/index.php

And I agree with the author about using FBOs, if we aren't already.

i am currently separating SM3 sync relevant stuff from the rest *eg only rendering relevant).
could someone please explain where the Vector3 class/struct comes from? it is used in some headers that have no #include statements, and do not define it them selfs. For example rts/Map/SM3/terrain/TerrainTexture.h.
i excluded some things already, and somewhere i also excluded something that seemed to have defined this, and now its not found anymore. also, could we no use float3 instead?