ATMOsphere

[Pazystamo]

Nice to see that someone still use this my little node

[sp00n]

Pazystamo
if you haven't anything against i'll add a moon, lenflare(may be:) ) and some optimization and shall post it here

[Pazystamo]

It is node for Irrlicht, so it can use irrlicht license. You are free to change everything Just add header in cpp file and write what you added.

[jingquan]

Hello, I'm wondering if the latest version works with DirectX? Because it dosn't seem to update in DirectX but works fine in OpenGL. I'm using a converted C# version of this but I just want to know if the problem exist in the latest orginal version.

BTW, here's a larger (1024^2) starmap I made: http://www.orandysoftware.com/user_files/stars.jpg

Thanks and enjoy.

[GrigoriosSokratis]

Hi, I'm implementing ATMO in my project, however I have two serious problems; one, when using it under Direct3D9 the sun doesn't behave normally and I think it doesn't move at all. Is there any way of making it work out with Direct3D9?

The second one, (and this one happens either when rendered under Direct3D and OpenGL) when I move the camera around the place the sun suddenly jumps out of its trajectory only returning to its proper place when I stop moving (this strange effect only happens when moving the camera while it doesn't when rotating it).

Thank you

[Pazystamo]

Hi,
If you are using newest version then it shouldn't be any problem with sun position. Or maybe new irrlicht version changed some functions calculations.
It should be in void update(video::IVideoDriver* driver) maybe cam->getAbsolutePosition(); updates differently. Or in CATMOstarSceneNode virtual void OnPreRender()
// make billboard look to camera
core::vector3df pos = getAbsolutePosition();
core::vector3df campos = camera->getAbsolutePosition();
core::vector3df target = camera->getTarget();
core::vector3df up = camera->getUpVector();
core::vector3df view = target - campos;
view.normalize();
it was something with onprerender, it take position one frame later as i remember...

[GrigoriosSokratis]

After literally tens upon tens of trials (all of them leading to the expected jerky sun error) I guess I found the two reasons of the problem.

The first one that cuts the jerky behavior to a 50% is clearing the sleep() command that cuts the CPU usage according to the specified number of milliseconds:

//Save CPU usage
DeviceDriver.device->sleep(50);

However in spite of the improvement the problem persists and the sun still shakes when moving around.

So, I have to point you out that my project contains a ground mesh of 40sq kms, plus a surrounding terrain node of 60sq kms totalling an area of 100sq kms.

The terrain nodes seem to not change anything when cleared, however that's not the case when the ground 3ds mesh is cleared from the code; and the sun quits its jerky dancing.

So, my conclusion is that, since it has to draw the whole scene (and we are talking about a really huge scene) it gives priority to the 3ds object over our beloved sun billboard, resulting in a few milliseconds lag that gives us as a final result the dirty dancing sun effect.

Unfortunately, I can't have this huge 40sq kms hole in the middle of the scene, as my project without its ground level has not any sense.

So, anyone knows how could I make the billboard get a higher drawing priority over the rest of the scene (specially the ground 3ds mesh)?

[Dorth]

Unless you've got parrallelism, there's no priority. All is rendered each frame. Dot. Also, if clearing it doesn't help, it's probably a memory problem first. Anyhow, something that might help you is an impostor. Look it up. That huge terrain can probably be replaced.

[GrigoriosSokratis]

Yeah that would be a good idea, but how could I implement the impostors of a huge ground mesh in Irrlicht.

I mean, how could I make a billboard of it and still make it look realistic as much as the original mesh.

Any ideas to enlighten me please, I'll appreciate that.

Thank you

[Dorth]

Depends how far it is. You'Re telling me you have multiple squared kms that must be seen at the same time. Well, that means they are far from cam and you should be able to do it quite easilly through any good impostor tuto

[GrigoriosSokratis]

Sometimes an image is worth a thousand words, here is a view looking to the south (believe me, to get to the part where the 3ds square mesh meets the surrounding terrain nodes we have to walk about 7 kms!!)

The area is huge and mountainous, so when looking towards different directions the landscape changes, so I don't know how many impostors are needed, as well as the number of chunks I'll have to divide the mesh proper, since if a user wishes to visit a certain part will have to replace the impostor for the real mesh; and all of this just because the sun has a small (but still annoying) jerky movement.

[GrigoriosSokratis]

Also, I just found a detail, the sun just does this jerky movement when first pressed one of the arrow keys to move the camera, once I keep it pressed it doesn't have any problem.

So it happens just when I press one of the arrow keys, or change the movement direction.

So it could also has to do do with something related to the Event receiver of the FPSCamera.

[Dorth]

First, Try, if possible, to code your own camera and not use the FPS one. It is not adapted to many of the situations. Second, I didn,t visualize your game like this. In your situation, you should most likely generate your terrain procedurally with LOD like some of the nods here do and forget having a 3ds for it. I seriously doubt it's a good idea.é If that fails, try and do like a normal level design. Put in one mesh all that is unique then generalize hills, lakes, etc. and just instance them.

[GrigoriosSokratis]

Hi, I'm working on that 3rd person camera currently, so let's see what the outcome will be. By the moment if you just implement a new custom camera the effect is even worse (as you can see the whole "interpolation" of the sun between its two extreme positions during the movement). But I found that just throwing a sleep(x) command helps and we are back to the initial problem. However, since I'm controlling this new camera's behavior, I'll try to code a sort of algorithm that predicts the next movement so positioning the sun to its next frame position before it happens; so let's hope this works out, cause I'm really going nuts with this situation .

Regarding the mesh, unfortunately I've already tested it with Irrlicht terrain nodes and the visual effects were even worse. As for the reason of using one 3ds mesh (designed out of real DTED elevation data), it simulates a real place, and it must look like the real thing in real life. So when in that place I need a visual range radius of at least 7-10 kms.

Now, when you are talking about LODS you mean making lots of 3ds's made up of different number of triangles? I don't know if in this case it would make for this situation as, when for instance a user climbs a hill or a mountain the whole area must be visible.

Thank you

[Dorth]

Err, why not alter the position of the sun IN your camera movement code?

Using a mesh for ground is not something I'd recommand at any rate, but yeah, lod is basically making version less detailed. You'd better chop your map in pieces and make 3-4 versions of each part (make sure edge are pretty much the same ) and then in your code, switch from one to another, if not hiding them altogether when out of sight.