Page 10 of 12

PostPosted: Tue Jan 03, 2006 7:51 pm
by sascha
Make them part of the tractor delivering the drilling machine to its launch site. The machine itself doesn't need to be any more than a bullet with a massive drill bit (like you would find in your toolbox) attached to one end...

Something like a launch pad? That's a cool idea! It also solves the problem of how the machine would start to dig vertically into the ground - although I love Davids drawing:
Here's a new drill:
There's obviously nothing that stops the machine itself from rotating when it starts the drill - but I think that doesn't matter.
I'm not sure about the colors. I think the launch vehicle should be yellow and have that genaral construction-equipment look. It should have a ramp where the machine is initially attached to.
The drill itself should have a more high-tech look - so I don't think that yellow is a good color for it.
What do you think?

PS: And sorry, I had a slight misconception about what a tread is - I thought you meant the groovings on the drill :?

PostPosted: Wed Jan 04, 2006 1:41 am
by squirrelhavoc
sascha wrote:PS: And sorry, I had a slight misconception about what a tread is - I thought you meant the groovings on the drill :?

Sounds like you got tread confused with thread :)

I really like the new update on the machine, I have no crits really. And about it spinning when the drill starts, it could always have a gyroscope in it to keep it stabalized. Don't know how you can convey that in the animation, but if anyone asks, you could just tell them :)

PostPosted: Wed Jan 04, 2006 1:48 am
by dcuny
Confusing tread with thread is understandable. :D

I like the idea of using launch pad for the driller as well. All the drill needs to do in Australia is pop out of the ground (like in The Incredbles).

I think the new design is much nicer than the old one. The bolts on the new design really help - the make it look like an old boiler. I like the color as well. Although heavy equipment is yellow or green, I think the metal look is best.

You might consider using other metallic colors - silver, copper or gold - for various parts of the machine. Nothing really fancy, just something to offset the grey.

My only complaint is that the screw's thread:
  • On your machine, the thread gets wider as it goes along the shaft. But take a look at the threads on the driller in The Incredibles, or even an ordinary screw, and you'll see that it reaches a maximum size pretty quickly, and doesn't grow past that point:

  • There's should only be one thread on the screw. I think that's why I initially thought is was too "twisty".
Then again, maybe that's this driller works and others have failed. ;)

Hrm... Is that another Inyo rendering? I see an odd aliasing on the left hand side of the door. I would imagine that it's perhaps confused because of the clear material, although this doesn't seem to be the case on the other side of the door... :?

PostPosted: Wed Jan 04, 2006 1:20 pm
by sascha
Yes, I've used Inyo for the preview. I'm not sure what's causing the aliasing artifacts. The semi-transparent blue glass of the doors also looks a bit odd - I'll make a "reference rendering" with POV-Ray to see if it looks different.
I've redesigned it a bit, here's a little test animation:

PostPosted: Wed Jan 04, 2006 6:11 pm
by dcuny
I like it, but I think the drill is longer than it needs to be. It's hard to tell, because the camera is panning past the driller.

After watching the video many, many times (looking for rendering errors), I finally notices the treads underneath the driller. I think they're a little too subtle.

The aliasing probably comes about because Inyo doesn't even consider oversample points unless the meet various critieria:
  • The material changes
  • There are reflections involved
  • The number of lights on the surface changes
Even then the point only gets resampled if the color differs by world.colorTolerance. You might try adjusting the value of world.colorTolerance (set in and see if you get better results. It should be made available to the user as a slider value.

That probably won't solve it, though. I think the problem comes from Inyo being able to compare the surface color if it's reflective or refractive, but not both. Try setting the glass to being transparent but not reflective. If that takes care of the problem, I know what to fix.

But I suspect that it's more subtle than that. You can see a similar aliasing effect at the top of the driller in the last frames. :(

I think the "wobbly" specular reflection on the drill is from JPatch's tesselation code, not Inyo.

I'm going to reconsider the oversampling logic, and see if I can make it more robust. I think it's pretty good, but as you can see, there are still some cases that are slipping through. I suspect that I can just add an additional color difference test, set to a higher value than world.colorTolerance. That way, really blatant changes on single-color materials will trigger oversampling, even if none of the other criteria are triggered.

PostPosted: Thu Jan 05, 2006 9:46 am
by dcuny
One (unlikely) possibility is that Inyo is actually flagging the pixels for oversampling, but they're slipping past because world.colorTolerance in is set too high. Setting it to a lower value will take care of this.

I don't think this is the case. Another way to test this is to set world.debugOversampling - also in also in - to true. Instead of oversampling, Inyo will mark "suspicious" pixels in red. If the areas with jaggies are marked in red, the problem is with world.colorTolerance.

But It's most likely that Inyo is never flagging the pixels as "suspicious" in the first place.

I doubt that you've got the time to try this out, but if you want to give it a chance, here's a change you can make to the code that might fix the jaggies:

Currently, Inyo only considers "suspicious" pixels as candidates for oversampling. It doesn't use color as a parameter for detecting "suspicious" pixels, because that tends to trigger too many false positives, especially when soft shadows or ambient occlusion are involved. Instead, it looks for changes of materials and edges of shadows.

As a workaround, I've added another color tolerance parameter. This one should be set fairly high (to avoid setting off a lot of false positives) to help catch cases that are currently passing through the cracks. So the color tolerance variables are:
  • world.colorTolerance: If any pixel surrounding a pixel differs by this amount, the pixel is flagged as "suspicious". This value should be set fairly high, in order to detect blatant jaggies.
  • world.materialColorTolerance: If any pixel around a "suspicious" pixel exceeds this color tolerance, the "suspicious" pixel is oversampled. This value should be lower than world.colorTolerance. (This will cause any pixels flagged as "suspicious" by world.colorTolerance to be oversampled).
This should take care of the problem, for now.

The first change is in, where world.adaptiveColorTolerance has been added:
Code: Select all
double adaptiveColorTolerance = 30; // 0..255. amount color must differ on adaptive sample
double colorTolerance = 60; // 0..255 amount color must differ on non-adaptive sample

Next, add a color tolerance test to the end of the tests in RtRaytracer:trace:
Code: Select all
   // base or reflected material not just a plain color?
   || (material != null && material.colorShader != RtMaterial.COLOR_RGB )
   || (reflected != null && reflected.colorShader != RtMaterial.COLOR_RGB)
   // color difference greater than allowed
   || canvas.needsResampling(RtCanvas.ABSOLUTE, b, a, world.colorTolerance)) {
      // flag as candidate for resampling
      needsOversampling[b][a] = true;                  
Finally, I rename the old variable world.colorTolerance to world.adaptiveColorTolerance:
Code: Select all
// check color difference
needsOversampling[b][a] = canvas.needsResampling(RtCanvas.ABSOLUTE, b, a, world.adaptiveColorTolerance);
if (needsOversampling[b][a]) {
This code is untested, but it should catch those pesky jaggies that are being missed. Again, you can set world.debugOversampling to true to see which pixels Inyo considers as "supicious". You'll want world.colorTolerance to be high enough so that it only gets triggered by jaggies, which tend to have pretty high contrast.

Again, if you haven't got time, don't worry about it - I expect that after the IRTC submission, I'll be able to get a (sort of) stable version of JPatch, so I can test these things out myself. :D

PostPosted: Thu Jan 05, 2006 8:33 pm
by sascha
Ok, I'll try.

I cought a cold and am not really in a mood for programming today :(
I hope that I'll feel better tomorrow, so I could use the weekend to add the missing features to JPatch and continue with the IRTC animation...

PostPosted: Thu Jan 05, 2006 9:03 pm
by dcuny
I know the feeling - everyone in my family seems to be sick, to varying degrees. It can be a real drag, and impossible to get motivated.

Ten days to go... You really like cutting it close, don't you? ;)

PostPosted: Fri Jan 06, 2006 12:39 pm
by sascha
I know the feeling - everyone in my family seems to be sick, to varying degrees.

Yes, it's the same here :?

Ten days to go... You really like cutting it close, don't you?


PostPosted: Sun Jan 08, 2006 9:54 pm
by squirrelhavoc
You're running a little short on time, I was wondering how long did you take to make Imposter?

PostPosted: Sun Jan 08, 2006 10:13 pm
by sascha
About a month. But it was a lot more complex than the current animation (especially taking into account JPatch's limited features by that time). Rendering took also quite long (there was a lot of geometry, a lot of lightsources and a lot of reflective surfaces). And lipsyncing was a real time killer (it was difficult to tell if it was right in the wireframe preview, so I had to render the shot, correct lipsyncing, render it again, and so on...)

This time there's no lipsyncing, and I'll go for a more cartoon like style, so I hope that rendering times will be lower and that I can create the entire animation within the last two days (just like I did the "Travelling" one with the Moais).

The real pity is that there won't be much time to post interim shots to get feedback (which was very important for "The Impostor"). I hope that the animation can still be competitive, but if not I won't be disappointed. The important thing is that JPatch's animation features finally start to work out.

PostPosted: Sun Jan 08, 2006 11:05 pm
by squirrelhavoc
sascha wrote:the "Travelling" one with the Moais

Now that you mention that, what are they saying in the animation? It's hard to understand with my speaker setup.

PostPosted: Sun Jan 08, 2006 11:08 pm
by sascha
I don't know, ask David :D

Seriously, I IIRC the dialog was something like
"You know, it would be nice to travel. London or Paris..."
"Yeah, it's a pity we don't have any feet"
"And we're carved of stone, and we're inanimate objects, and..."
"It's a pity alright!"

PostPosted: Mon Jan 09, 2006 4:46 am
by dcuny
The mix was my fault - it sounded fine through my speaker system and headphones. It was only after I heard the mix on my parent's computer (which has cheap speakers) that I realized exactly how muddy it sounded.

Chalk that one up under "lessons learned"... :roll:


PostPosted: Fri Jan 13, 2006 11:13 pm
by sascha

To be honest - I doubt that I can do it in time.
I've found some bugs that need to be fixed - and the timeline and the FK controls are not ready yet - it will take me at least one more day to make them useable - so there would be just one day remaining to create and render the entire animation. I tried to animate one shot with the tools as they are - it is possible, but very cumbersome - using the sliders is ok for fine tuning, but to setup a pose, FK handles in the viewports would be very handy.
And being able to copy some keys from the timeline and paste then to another frame would also be nice...
Last not least, there's a bug in the animator - The more I work wirth it, the slower it gets - I'm sure it's something simple, but I just haven't found it yet...

I'll give it another try tomorrow, we'll see.

Not making this animation would be a real pity, since I like the story and I think that it could be done.

But at least JPatch is definitely ready for the next IRTC round, and who knows, perhaps the models and some parts of the story can be re-used.