DayOfWar more Asteroids

#1 Impressed with your updates every time man. That asteroid looks awesome.

#2 Two links point to the same animation. But very cool.

#3 Niiice!

#4 looks better with every update, good to see such progress

#5 @ Andy - Thanks for pointing out the link error. It is fixed now.

#6 Awesome.

#7 Again: awesome stuff!!

PS: Can't help but note once again what a poor job Atlas is doing with handling LODs here. Hope that's going to be fixed real soon now.

#8 @Rene Damm - At first I thought the terrain popping was the bounds for the chunks being incorrectly computed in my exporter.
But creating a standard "flat" atlas with the same source files still causes popping/jumping effects in the same areas as the round atlas files.

On a side note if I load the same atlas file in 1.0.3 the popping is greatly reduced and the textures don't get mixed up sometimes like in 1.7.0.

Just to correct something I said in this plan.
The pointy asteroid was created with a spherical projection instead of the six sided cube method I described before.

#9 How many lbs of Diamonds and Gold did you mine from them? (cool joke :) )

#10 @Bill
The popping and jumping is indeed a problem of stock Atlas. It shows as soon as the geometry tree gets deeper. Usually I get this above level 4 or 5 or so. Atlas also seems to mess up the collision meshes in these cases. If you walk on surface, you will have places where you can actually walk *into* the terrain surface.

The fact that popping is greatly reduced in 103 is very interesting. Unfortunately, I don't have access to those sources as that was before my time. Would like to find out what has changed.//Edit: Silly me. Will ask Matt about this.

The texture mixups are fixed now. That was a miplevel problem.

IMHO Atlas has massive issues at the moment. There's virtually no way to produce a terrain of proper dimensions and good texture resolution that renders correctly (regardless of whether its unique or blended). Either Atlas pops and morphs all over the place (deep tree) or it drops clip levels (shallow tree).

Today I also made the shocking (at least to me) discovery that Atlas renders out all of the terrain at virtually one single fine tesselation level, i.e. it decimates the mesh according to maxerror and then basically seems to replicate the same finely tesselated mesh at each LOD level. I'm not sure yet whether this is because activation levels are computed incorrectly or because of something else.

Essentially, this means there currenctly isn't any *real* level of detail for geometry in Atlas at all.

It is still my sincere hope to have any major issues out of Atlas by the time 1.7.1 ships.

#11 @Rene Damm -

Quote:
The popping and jumping is indeed a problem of stock Atlas. It shows as soon as the geometry tree gets deeper. Usually I get this above level 4 or 5 or so. Atlas also seems to mess up the collision meshes in these cases. If you walk on surface, you will have places where you can actually walk *into* the terrain surface.

Funny you should mention this.

For a variety of reason I have found that a tree depth of 4 is optimal for me.
Less than 4 there are areas of the map where the rendered map doesn't match the collision geometry ,Player sinks into map and sometime the collision geometry seems incomplete and the player will fall thru the terrain.

Above 4 and ,because my game requires fast moving vehicles near the terrain, to much LOD loading and unloading occurs.

It just seems to me that in general that 1.7.0 will skip right to popping a LOD chunk as oppose to morphing it like it is suppose to.

#12 @Bill Vee

The problem with a geometry tree of just four levels is that with any decent texture size (which tend to be even larger for blended terrains), you need a *real large* clip map in order to see all clip map levels. With lower sizes you will either not see the higher levels at all or, almost worse, you will see them in one chunk but not in other adjacent ones resulting in visible texture seams.

The further you are from four clip map levels the more level dropping you will see.

#13 Hey Bill. Love the work you're doing with planetary effects and physics and such. My favorite thing are the waterSpheres. If you could set up a sun in the right position and get a shot of a player standing on a coast looking out, no doubt it would be amazing. I'm trying to do something similar in my project involving planets and was hoping you wouldn't mind answering some questions I have.

Whenever my player runs around the planet and hit the equator (so that he would be inverted and on the southern hemisphere) all left-right movement and viewing inverts. I also have a ton more bugs when standing right on or very near the equator. Did you ever experience this? I haven't upgraded to TGEA yet (just testing to see if it is possible for me to implement my ideas first), I doubt it but, any chance this is responsible?

Unless it's a big secret so far would you mind revealing a little more on how you implemented your gravity? You said in your oceans blog that the wheeledVehicle required no changes and others only took a dozen lines? Didn't you at least have to add gravitational velocity to them?

Thanks and great work on your game :D

#14 @Morrock - The Player class is not suited for planet type movement.
The reason for the inversion on the controls is due to how the player class uses a very simple collision box.

If you take a look at the Player::findContact function it alters the contactNormal based off of up and down being in the z plane.
Since contactNormal is used later on in updatemove to adjust the player's requested direction to be parallel to the contact surface the movement gets messed up.

Judging by your post it sounds like you used the conform to terrain resource.
I went the same route and learned a lot from it.
Unfortunately simple changes to the player class didn't work for me.

I had to write a custom class to do the job.

As for the gravity it is a class I created that is very similar to the physicalzone class.
I will likely release some resources later on the gravity.

#15 @Morrock - It appears I mis-spoke about the wheeledVehicle. I did have to add one line to the updateforces function. The wheeledVehicle was the easiest vehicle to get running correctly with planets and I forgot I did make a change to it.

#16 Thanks for the quick response,

Yeah, you caught me on using the conform to terrain resource. Actually I started off using it, but then changed the use of a surface normal direction to a vector which is an angle of players location relative to the point of gravity (which is also how gravity forces work.) So they can run into cliff faces and such without flipping over. I hadn't thought of changing that in findContact however, though I doubt 1 line will fix it.

Making a custom class? Ouch. I'd really rather avoid all that, but if I have to I will. I'll spend one more day seeing if I can find a fix with what I know now, if not...

Haha, I though it would be wierd if vehicles just suddenly worked. I haven't worked with vehicles yet, but I'm assuming because they already conform to terrain there aren't many problems with planets? Maybe I should take a look at that class :p