Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


slayemin

Member Since 23 Feb 2001
Offline Last Active Nov 21 2014 08:47 PM

Posts I've Made

In Topic: Corrupting of the view if far from world center

13 November 2014 - 05:33 PM

How to use doubles to get more precesion? Could you write about this more detail?


I hesitate to suggest this because of how ridiculous it really is, but you'd essentially have to create your own Vector3 class which uses double instead of float for the X,Y,Z values. You'd also have to do the same thing for your matricies. It's doable and you'd get a lot more precision, but it's a lot of work.

Class Vector3Double
{
double m_x, m_y, m_z;
public new Vector3Double(double x, double y, double z)
{
   m_x = x; m_y = y; m_z = z;

}

//etc.. what a tedious pain in the ass.
} 

 
 
 

How translating the whole world to fixed distance could cause bugs? Dos it not the same as moving the whole world?

 
For example, let's say you have an object and that object is at position 10100,10100,10100 and it is trying to get to position 10200,10200,10200. You subtract 10000 from the object position, but you forgot to subtract the same amount from the position the object is trying to get to. Now, the object is at 100,100,100 and trying to get to 10200,10200,10200, which is wrong. The more objects you add, the more chances you have to forget to do something and mess things up. More complexity = more room for human error.

 

BTW, I susprect, that game logic gets more complicated if I need to move the whole world with many objects instead of one camera. What if I want to move not only camera. but also binded object? I need to move everything except 1 model and camera? Did I undertand you correctly?


I haven't done this myself in my camera code, but if I was going to move everything relative to the camera, I'd still want to keep my objects in their own world space but keep the vertex info as close to 0 as possible. To do this, I'd actually store an offset vector inside the camera object. If you move the camera forward, you're actually just changing the camera offset value by the forward vector. Then, when you go to render your object models, you'd use the camera offset value as a final translation within the models transformation matrix. Sure, objects farther away from the camera *might* suffer from floating point precision errors, but they're *far* from the camera so you cannot see that anyways!

This would also work much better than keeping a global offset since you can still use multiple cameras. Each camera is at its own (0,0,0) but knows how much to offset the world by to get its own view of the world. I guess you can pretty much just think of the camera offset as the negation of the camera position (which would actually be smarter than maintaining a separate offset value!)

Vector3.Zero = Camera.Position + -Camera.Position;


In Topic: Cant get this third person camera coding working

13 November 2014 - 04:58 PM

Yeah... I'm not going to look through all of that code for an error when I don't even know what the error is or what to look for.

 

If the camera isn't even moving, are you even sending the camera "movement" commands? what if you just send the camera a "move forward" event every frame, independent of input?

Is it wired up to an input controller? Is the input getting through and firing the move event?

Is the camera getting the move event?

Is the move event actually moving the camera position?

Is the camera position correctly calculated based on how much you need to move the camera?

 

If your camera moves forward and back, and side to side, then you're already 95% of the way there.

 

for mouse movement, or rotation around the up vector, you have to send the camera a delta angle on some axis vector (or modify a quaternion if you're using those). If you're doing that but getting funky results, your math is probably wrong.


In Topic: Corrupting of the view if far from world center

13 November 2014 - 04:48 PM

Yep, its almost certainly caused by floating point precision errors. The farther from 0 a value gets, the less precise a float gets. I think the step size between float values increases exponentially as you get further and further away from zero.

 

With your airplane model, what ends up happening is that the calculated vertex positions hit on a value which is between the ranges of a float, so the float just truncates the value? (or it might round?). ie, 9.00000000001 would fall between the value 9.0 and 9.0000000000234, and just become 9.0. The visual effect is that the airplane model verticies get mushed together and the end result is something that looks like a bad low-poly version of the plane.

 

What's the fix?

A) try to keep your floating point values near 0 because the step values are very close

B) use doubles to get more precision on higher numbers (Though you're just kicking the problem farther down the road)

 

Techniques & options:

A) keep the camera at 0 (as mentioned above) and move the world around the camera, easiest solution with least complexity

B) At certain fixed distances from 0, translate everything in the world to recenter on zero (ie, at 10k, shift everything by 10k to get back to 0). This can get tricky and cause bugs.

C) Just use smaller worlds in your design

D) Scale the world down


In Topic: Science Lesson: Facts, Theories, Hypotheses, and Postulations

11 November 2014 - 01:59 PM

 

Frankly, I don't see the point of this thread. Everyone here understands the scientific method and the difference between data, hypothesis, theory and law.

That is because you haven’t understood the point of the thread (sounds redundant, but how else could I say it?).
You seem to think that theories are only facts when you put a semantic twist to things. Like so many others, you think that saying “gravity is a fact” or “evolution is a fact” it only means, “if we consider theories as facts.”

The point of this thread is that I am tired of explaining this over and over.
Gravitational theory is a theory because gravity is a fact.  There are no semantic plays happening here.  Whether there is a theory or not, gravity still keeps us attached to this planet.  Gravity was a fact before it ever occurred to Newton to form a postulation/theory.

 

Bregma was correct until he said “gravity is not a fact”.  Gravity exists, which makes it implicitly factual.  Saying something “factually exists” is redundant and saying something “falsely exists” is a contradiction (it is not the same as saying something exists in fiction).

 

 

L. Spiro

 

I hate to nitpick when you're 99% correct, but if we're being precise I think it's worth being slightly more pedantic.

Fact: Stuff falls to the ground with a measurable force, where F = ma.

We have a well accepted theory on that which (mostly) explains the how and the why, and we call it the theory of gravity. Within the theory of gravity, we call this attractive force "gravity". 

Let's make up a fictional competing theory for a moment: There are angry gremlins in the center of every sufficiently massive body which use magic spells to bring "stuff" towards them, and we'll call this attractive force the "gremlin factor". 

"gravity" isn't a fact any more than the "gremlin factor" is a fact. They both only have representational meaning in the context of the theories they come with. They're both explanations of an observed phenomena. You might reply and say, "well, I don't mean 'gravity' is the fact, but the thing it represents is the fact.", and that's what we're trying to get at and clear up.

 

Why does this matter?

 

In principle, we need to be careful to discern the facts from the theory so that if we have to discard the theory, we don't discard the facts with it. Or, if the facts are wrong, it may not necessarily mean that the theory is wrong (though you need to be extra careful with this). Or in same cases, both fact and theory could be completely wrong!

 

As a historical example, Greek astronomers used to have a model for the solar system called the "Ptolemaic model", where they observed planets moving forwards, then backwards against the backdrop of the sky in what appeared to be circular loops. Indeed, their observations actually saw planets moving back and forth in loops in the sky, and they could claim that it was a "fact" they called "epicycles". Except in truth, epicycles don't actually exist -- it's an illusion. Within the context of the ptolemaic model, they existed as observable facts which come with a really complicated explanation. 

 

Another historical example from 1903 -- N rays

 

If we get too attached to our apparent facts as being correct, we run the risk of creating flawed theories and have no way of knowing they're flawed. The theory of gravity is quite well accepted in the scientific community and it explains a lot, but there are some things it doesn't do a good job of explaining: why does matter have gravity? where exactly does it come from? If another theory comes along and explains all of the things the current theory of gravity explains and more, but it requires us to shed our belief in the current "fact" of gravity as we know it (ie, it's just our modern version of epicycles), then we must be able to do so by saying that 'gravity' only has meaning as a fact within the theory of gravity. (plausible counter-theory: "gravity doesn't actually exist, matter just warps space-time and the warping of the space-time is what causes the attractive force we experience.")

Maybe this is getting too deep into the philosophy of science though. You're totally on the right track though.


In Topic: Game reviews from developer's perspective

10 November 2014 - 05:47 PM

Heh, what are you looking for?

"Hmm, these particle systems seem to be pretty good! I like how the point sprite always faces the camera...as it should!"

 

Most of the game engines in use these days take care of the technical how-to's so I don't think you'd get a lot of variety in the technical reviews. If you want the deep dive on the technical aspects of a game, you're not going to get it by looking at the game play interface a player would see.

 

As far as the game design goes, that's a lot harder to review because its not really something tangible and readily evident.
"Oh, I think they're using a variable reinforcement reward system here using equation XYZ with the constant values ABC."

 

The reason you usually don't see these types of technical reviews is because the audience (game developers) is very small and there isn't really a reason a fellow game developer would need to "review" another developers game. What do either parties get out of it? Nothing. The game has already been shipped and the technical how-to is generally something we can figure out for ourselves if it's not already solved with our tools. If there were bugs / problems, it should have been caught in pre-release QA, not a post-release review.

As far as we're concerned, it's "Hey, congratulations! you shipped a game and it sold really well! Looks like you still have jobs!". That's the only review we really need and we don't need other developers to tell us if we did that well -- the sales figures will tell us that.


PARTNERS