Basic theory question

Started by TheBadger, February 21, 2014, 04:30:59 pm

Previous topic - Next topic

TheBadger

Hi,

1) Suppose the earth was just like a TG2 default planet. Smooth and round and without "displacements". Now suppose the default planet in TG is the exact size of the earth.

2) Now imagine a digital you; A skinned and rigged object, that has a single animated walk cycle. The walk cycle is just how you walk at "normal speed" in a normal environment; on a sidewalk for example.

3) IF your digital self was put on the TG planet and set to walk in a straight line, where you do not stop walking until you return to the starting point, Would the amount of time it takes to walk around the world be the same in TG as it would be on the earth?

Just curious.

Thanks.

It has been eaten.

yossam


TheBadger

I wish I had the disposable income required! I would do it just for the heck of it. ;D
It has been eaten.

Oshyan

I don't really understand the point of your question. The planet in TG is basically the size of the real Earth, or the idealized sphere of Earth-size (it is not quite the same shape as the real Earth bows out at the equator slightly, i.e. it is slightly compressed vertically). IF you had a "walk" function in TG, or rather, a camera with a "walking pace" movement setting, then yes it would take you the same amount of time to "walk" around the TG planet as in real-life, or put another way, a helluvalong time. ;)

So basically the summary answer to your question is: yes
But it's based on several things that TG doesn't have in it at all, namely object animation and "walk cycle".

- Oshyan

mash

Circumference of the earth at the equator is 24,901.55 miles
average human can walk 3 miles per hour

So 24,901.55 miles divided by 3 miles per hour =
8300.516666666667 hours

8300.516666666667 hours divided by 24 hours in day =
345.854 days to walk around the equator non stop
(*note no bathroom breaks included)
(If you had to go through U.S Customs you can add about 24 hours on the trip to fill out paper work and answer questions)

Now the fun part.
24 frames per second X 60 seconds = 1440 frames per minute
1440 frames X 60 minutes  = 86400 frames per hour

86400 frames per hour X 24 hours =
2073600 frames for 1 day of animation

2073600 x 345.854 days = 717162854.4 frames
That's how many frames you need to do an animation of you walking around the earth.

Don't ask me what that is in 25 FPS, or NTSC 29.97 drop frame. :)

I suck at math so take those numbers with a grain of salt.
Egads I need a life.

TheBadger

^^ HA! Now those are some sick numbers!

But its funny, we have to double the total because Oshyan won't loosen his Kung Foo death grip on reality and have a little fun.
so 717162854.4 frames x 2  = 1434325708.8 frames... after rendering the walk cycle in another software for compositing...

I think its worth it though! Lets do it! Who's with me?

Anyone? ? ? No one?... Chickens!




It has been eaten.

PabloMack

February 23, 2014, 09:59:22 am #6 Last Edit: February 23, 2014, 10:03:31 am by PabloMack
The problem is that, unless your model's walk cycle had the right curvature in its base line, it would walk out along the X/Z plane right off the surface of the planet into space. Supposing you did such an animation, who would watch it? It would be a LOT more boring than watching someone actually walk around the Earth. And who would want to spend so much time watching basically the same thing over and over and over and over for many months?

If you really wanted to do it, it would be faster to render out one walk cycle and then copy that clip into your editor a kazillion times. Rendering that would be a lot faster. But who has the hard disk space? I think you are just yanking our chains.

mash

You want a really scary number?
try to figure out how long it will take to render 1434325708.8 frames

I think this is just a little fun mental exercise while waiting for the TG3 update to come out.

TheBadger

QuoteI think this is just a little fun mental exercise while waiting for the TG3 update to come out.


I love a man who can see the forest from the trees! Besides, Its an interesting way to understand VR (of a kind). When I show people in my life the stuff I do with this software, they are always impressed when I talk about how my TG world exists in Virtual space at the same size as the real world.
I don't have anyone in my personal life who understands this stuff like the people in this, and other 3D communities do. Describing it to them in terms like my OP really helps me make sense to them about what we do here, visually.

I did understand intuitively that the answer to my OP was yes, but never heard that "yes" facually based before. I just assumed it.

But to pablo's point... Its not about watching it, its about the idea that some lunatic actually did it. And that its playing year after year somewhere on line. LOL, come on! Wouldn't you just feel better knowing it was out there?  ;D  :P Party pooper.
It has been eaten.

Dune

QuoteWhen I show people in my life the stuff I do with this software, they are always impressed


If I tell people what I do, most look kind of stupified at me and don't understand a word of what I'm saying. I can't get into their heads that all these trees and stuff are made up of tiny virtual triangles, and they quickly change subject to the nice shoes they recently purchased for half price.

TheBadger

Oh man do I know what you mean, Ulco.

The worst is when people think the computer does all the work and I just turn it on and off. Or when people bring me lousy photos to "fix"... Because thats just easy, all I have to do is put the photo in the computer and click a few times, and then the bad wedding photos wont suck anymore  ::)  pfff!
It has been eaten.

mash

Oddly enough questions like this are rather useful.
I used to work tech support for Lightwave. One day we found out there was a problem with the programming used for Inverse Kinematics. For some odd reason it would not work right when you tried to do IK on a character that was 600 feet (182.88 meters) in height. I have no idea why someone needed a 600 foot high character but they tried it and found out the IK broke.
Same thing with Mental Ray, if you tried to do large scale scenes it would take forever to render. Scale the scene down to a few meters and it worked ok. Not the best solution but it worked in emergencies.
Sometimes you learn things by doing what your not supposed to.

As far as telling people what I do I found it's easier if you just tell them it's an oil Painting.
Even if they are looking at it on a Computer monitor. They burn out less brain cells that way.



PabloMack

Reminds me of how I found out the hard way that Modo can't manage planet-sized objects. I was trying to do something with one and the navigation didn't work. One of their forum people told me to make it small, work on it then scale it back up. I think it is the range of the numbers they use to store coordinates. Probably no one expected anyone to animate a 600 ft. tall object so the software designers selected the ranges that the numbers could represent so that they would have more precision at the low end without having numbers that had to store too many bits. They were trying to limit the amount of storage it would take to store the object, animation or whatever it was. Efficiency can turn around and bite you in the rear.

gregtee

Actually it's called Precision Error.  The farther you move away from the origin, the more likely you are to encounter it.  It manifests itself in all kinds of ways.  It can take the form of exploding textures, jittery animation, etc.  It was explained to me once that it's like running out of math; at some point there aren't enough decimal places to properly describe your scene.  When that happens everything starts to behave abnormally, especially displacements. 
Supervisor, Computer Graphics
D I G I T A L  D O M A I N

PabloMack

March 02, 2014, 08:39:12 am #14 Last Edit: March 02, 2014, 08:42:00 am by PabloMack
Yeah. "Precision Error" is from loss of bit information off the low end of the number. "Range Limit" is when you run out of bits at the high end. These are actually two different but related problems. When you decide that you have only so many bits to represent your numbers, sliding the number representation down to get more precision, you lose range at the high end. When you  slide the number up to get more range, then you lose precision. The only way to get more of one without losing some of the other is to increase the number of bits representing the number. But this means your files require more storage and sometimes it means your program has slower execution. Jitteriness is caused by precision error as you say. But catastrophic failer for something being too large is caused by passing the range limit. There's no free lunch.