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.
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.
Last edited by Argh on 01 Jul 2009, 21:14, edited 1 time in total.
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.
imbaczek wrote:latest installers indeed should have that file.
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...
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...
You can start by reporting which bugs still need attention.
Hoi wrote:When I terraform/fire a weapon that changes the map the area that gets hit loses its texture and the texture becomes some kind of groundscar.
Hoi wrote:When I terraform/fire a weapon that changes the map the area that gets hit loses its texture and the texture becomes some kind of groundscar.
Could you post a screenshot of this?
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...
Auswaschbar wrote:
reivanen wrote: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.
Kloot, you wil be a rich man afterwards.
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)...
Kloot wrote:You can start by reporting which bugs still need attention.
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.
Master-Athmos wrote:
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...
Cheers, that should no longer happen for any ground decals. (If you want to test, be sure to update springcontent.sdz too.)
jK wrote: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!
It isn't, nothing in the SM3 code enables alpha testing.
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.
In current master? There was a problem with FBO binding/unbinding up until a few days ago, cannot reproduce it anymore though.
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?
