dgets / sol-cosmology Goto Github PK

Create a function that will accelerate the pace during the stretches through the voids. It shouldn't be so hard if the 2 initial coordinates (start and finish) are entered to figure out the distance and break it down so that each trip between celestial bodies takes the same 5 seconds or whatever arbitrary duration.

The display code for the non-transit portions of the animation is an absolutely atrocious stub, which has pretty much 0 chance of doing anything that we want it to. Let's work on that bit of code, as well; at least we can knock out half of the frames at that point. It shouldn't be very tough to add a rotating camera angle, keeping focus on the closest body to the camera, and continue the motion through the solar system while doing so. Just need a bit of a selective process based on the total frames and frame number.

First off, review the information that is available in the main issue and comments on #6. There are some things there that may be applicable.

I haven't looked at a full sized view of all 201 slides of the animation, but I don't think that that's necessary at this point. With the vector that the camera is traveling on, there should've been, at the very least, a sun receding in the background. However there happens to be absolutely nothing. Check the course, light sources, and other details between this last anim attempt and the first, which managed to show at least some of the heavenly bodies.

Perhaps we're going to need to start breaking the animation vector down into each planet-centric stretch, in order to finer manipulate the camera angles, and to verify that something is in our field of view.

I believe the testing cameras have only been implemented for Sol & Mercury so far. Need to add the rest to make sure everything is where we need it to be, as well as to maybe implement some better coloration or textures at some point.

There's something going on, probably with the following snippet, causing every 20th (and sometimes the following) frame to appear as if it's coming from within one of the bodies.

#declare ViewOrTransit = 1;	//1 for view, -1 for transit
#declare tmpFromMod = mod(frame_number, 20);
#if (tmpFromMod = 0)
  #declare ViewOrTransit = ViewOrTransit * -1;
#end

perhaps the mod statement isn't the way to be doing things here...

Not sure what the hell is going on (obviously), but the camera directly over Sol, looking down on everything, isn't working at all. This may be due to an issue with the system's equatorial plane object; I haven't had a chance to test out that theory yet.

This will be the first (very rough) animation fly-through that I'm doing with the scene. I'm not trying to be pretty/aesthetic with it, I just want a fly-through that'll display every object that I've placed so far, with at least a few different camera angles per object.

Wow. Talk about a pain in the ass:

povray: backend/lighting/radiosity.cpp:324: virtual void pov::RadiosityFunction::BeforeTile(int, unsigned int): Assertion `(pts >= PRETRACE_FIRST) && (pts <= PRETRACE_MAX)' failed.

Initial attempts at researching this have turned up the following news and bug reports at povray.org.

Having problems with the sun as a light_source with the looks_like directive. Not sure how to fix this right now, so I'll probably just go old school with it for a bit, in order to keep making forward progress on the model.

Though there are currently some light_source objects implemented, they're not yet in proper placement(s). Other than, perhaps, the ones for Sol & Mercury, they only exist midway between the orbits of the different bodies, with the light sources residing on the equatorial plane. There will, at least while the plane still exists for testing, need to be light sources above this, as well.

As annotated in the vector identifiers page of the POV-Ray documentation, it is possible to consolidate all 3 related coordinates in a single variable, or declared value, in order to keep things from getting so messy. After looking at some of the animation code, along with the coordinate determinations & mathematics, it'd probably be a good idea to start implementing this as soon as possible.