Animator...

Anything related to a beta release of JPatch: Bugs, enhancements, general discussion...

Postby sascha » Sun Mar 13, 2005 1:00 pm

For Aqsis on Linux: I too had the segfault problems when I compiled Aqsis from source :? The precompiled Frdora-Core-1 rpm works fine (on FC2 and FC3)...
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby pndragon » Sun Mar 13, 2005 3:00 pm

dcuny wrote:How did you launch JPatch? By default, Java only allocates 64 Meg of memory for the JPatch, which has to also be shared by Inyo (it's compiled as part of JPatch). That should be enough if you've got the mesh resolution down low, but for a 64 or higher, Inyo will silently fail.

Try launching JPatch with something like:
Code: Select all
java -Xmx512m -jar JPatch.jar
and see if that fixes it.


Still no good for Inyo...
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby dcuny » Sun Mar 13, 2005 7:22 pm

Have you got a test scene you're willing to share?

Keep in mind that you'll need to include all the models used in the scene, because that animation file just includes references to them. If you don't feel comfortable posting them, you could email me (or Sascha).
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby pndragon » Sun Mar 13, 2005 11:35 pm

This is my test scene as rendered by POV-ray:
Image
The scene file is test. The central object in the scene is lighthouse.jpt. The other objects (ground plane, metal spere) were included in the download for jpatch_20050205 and you should already have them.
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby rjh » Mon Mar 14, 2005 3:41 am

Hi all,

The best format is .mpg - never a problem playing them on any platform


Thanks David. I'll start adding that as an available format to accompany MOV & AVI. Do you know of a good converter that will make MPG from uncompressed AVI or image sequences?

I have finished some animation/render tests with the 20050311 Jpatch. I rendered 3 different animations with BMRT and then did the 2 shorter ones with Inyo on Win 2000 Pro sp4. Here's what the render times were:

All at a res of 472 x 200

project bmrt inyo
======= ==== ====

dm/200fr 47min 25min
nt/171fr 36min 9min
grp/719fr 6hrs27min

First time I used Inyo ... I liked its speed and look. I'll use it more now that I have it working. Great job David. Follow the link to a Jpatch page I just put up for the test animations. This is a simple page that I will update with more Jpatch info later. For now, it is just for you guys to view.

http://www.smartcomix.com/projects/jp03 ... index.html

Robert
rjh
 
Posts: 179
Joined: Thu Dec 30, 2004 10:33 pm

Postby dcuny » Mon Mar 14, 2005 5:21 am

The problem is (as with the refraction code) half the normals on the sphere are wrong. Fix them and render it again. I get:

Image

The scene you sent me only has one light, and yours has two, so that's not a big deal. The lights are definitely placed in different positions, but Sascha's already aware of that issue.

But there's no texture on my image, and it is part of the object description, so it looks like I broke that part of Inyo. Sascha, can you look into this? I changed the code a bit, so in RtPathNode:calcLights() you'll find the code:
Code: Select all
// set up float values to store the reference position
//hitTriangle.calcAverageNormal(world, this.hitPoint, this.direction);
Point3d pRef = hitTriangle.getReferencePosition();
float refX = (float) pRef.x;
float refY = (float) pRef.y;
float refZ = (float) pRef.z;

// is there a texture, and does it have a pigment?
if (material.texture != null && material.texture.getPigment() != null) {
    // get the color in world space
    Color3f c = material.texture.getPigment().colorAt(refX, refY, refZ);

    // set the color
    materialRed = c.x;
    materialGreen = c.y;
    materialBlue = c.z;
   
} else {
    // use the default material colors
    materialRed = material.red;
    materialGreen = material.green;
    materialBlue = material.blue;
}
This isn't an error, but the code should be something along the lines of:
Code: Select all
// set up float values to store the reference position
//hitTriangle.calcAverageNormal(world, this.hitPoint, this.direction);
Point3d pRef = hitTriangle.getReferencePosition();

// get the pigment or material color
Color 3f c = material.getColor( pRef );

// set the color
materialRed = c.x;
materialGreen = c.y;
materialBlue = c.z;
I suspect the error lies in RtMaterial.getPigment(), although I don't see anything obviously wrong with the routine. Feh, I must have been asleep when I coded this. :?

Robert, what platform are you using? I had a look at some of the animations you posted, and didn't have any trouble playing most of them under Linux. The exception was dmWalk_jp_18fr_indeo_bc01.avi.

I noticed a bit of banding on some of the images. I think I'll add some jitter to the initial sample, which will hopefully take care of that.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Mon Mar 14, 2005 9:59 am

David, I'll have a look at the materials support and the light-source problems with the Inyo export.
About the normals: Inyo should not crash or deadlock if the normals are facing the wrong direction.
But since this is still a problem (you'll get lots of rendering artifacts), I'm going to add the support for bicubic patches (either directly for POV and RIB or tesselated into a triangle grid for Inyo). This will trade the rendering artifacts caused by backfacing normals against cracks and creases in the surface :?
Anyway, with bicubic patch output re-enabled you can render any model without taking care about the normals. If you want to render it without creases, you'd have to align the patches and render it as mesh or SDS.

Note that there are still problems with 3-sided patches, especially at the center of rotations. I'm working on it...

About encoders: TMPGEnc is by far the best mpeg encoder I know of. MPEG-1 support is free, and it playes back on all mpeg players I know.
On Linux I use mplayer, with the additional codec-packages available on their website it playes back about every multimedia format you'll ever see.
It seems that they have modified their homepage, claiming that it has been shut down due to patent infringement to express their anger about software patents. This has not yet happened, the link on the bottom of the page leads to the mplayer homepage.
The background is that the european commission tries to enforce software patents and intellectual property laws (currently EU laws ban software patents) against a huge majority within the european parliament - I guess that's what we call democracy :(
There are some really stupid patents waiting in the wings, including such nonsense as mouse-pointers, progress-bars, etc. - if they get away with that, be sure to have a good lawyer at hand if you ever dare to write free software :?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby sascha » Mon Mar 14, 2005 10:46 am

Robert,
nice animations!
It's difficult to animate arms or legs with morphs (morphs are useful e.g. for facial expressions, lip-syncing, etc.) - I'm working on skeletal animation features to make animating things like walks easier in the future...

And yes, deleting temporary files was disabled by accident...
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Mon Mar 14, 2005 11:22 am

Inyo won't actually deadlock when it encounters "bad" normals, but it does take a terribly long time once it hits one. I haven't quite figured out why. You can see this if you launch JPatch from the command line, since Inyo displays debugging information as it's rendering.

I'm still struggling to figure out exactly what I'm misunderstanding here; I know I'll find it eventually. :?

Thanks for looking into the material problem. I should probably hold off on doing much Inyo code until you release the JPatch source. That's just as well, since I'm backlogged on wxBasic, and have a lot of research on shaders, hair and fur I need to do.

If you haven't already, would you add a routine to the API for catching the "advanced" material information that's sent back to Inyo? I should call RtMaterial:ParseShader() or some cleverly named routine. That way, when you release Inyo, I can start debugging the existing shaders, and adding some new ones. :D
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby pndragon » Mon Mar 14, 2005 2:47 pm

The scene you sent me only has one light, and yours has two
:oops: sorry... that is the default light that Sascha had pasted into
POV-ray... I just never took it out.

I fixed the sphere and re-rendered: 4423 seconds. I'll post the picture later... It looks really good even if it took forever.

Later...
Image
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby rjh » Mon Mar 14, 2005 5:38 pm

Hello everyone,

Robert, what platform are you using?


Hi David - for production, I am currently using Win 2000 Pro sp4. I also have an active Win NT 4.0 sp6a and Win XP Home Edition for testing viewability of my web page (Netscape, IE, & Firefox). I am currently shopping for a new production box (2 or 4 processor). If I go with another 2 processor, I'll convert my current 2 processor box (dual PIII 933) to Linux. If I go 4 processor, I'll make it a Linux box and keep my current 2 processor box as Win 2000 Pro.

I had a look at some of the animations you posted, and didn't have any trouble playing most of them under Linux.


That's good to hear, and surprising ...

The exception was dmWalk_jp_18fr_indeo_bc01.avi


Not sure why that one would cause a problem. The "indeo" tag in the file name indicates that it was encoded with Indeo 5.1. You will notice the "Indeo | Xvid" text under the animations listed under the "AVI" section of the page. This means that the ones on the left were encoded with Indeo 5.1 (a very standard Windows avi codec) and the ones on the right were encoded with xvid (the precursor to Divx; xvid development is still active). I like xvid best - smaller files; little to no artifacting ...

I noticed a bit of banding on some of the images.


I did as well ... thought that I would use that as a "feature" for "toon" rendering by cranking up contrast on post processing. These are afterall cartoons, right? => Great work on Inyo David. I plan on using it extensivly as a contrast to BMRT & 3Delight and because it's fast and I like the look it generates.

About encoders: TMPGEnc is by far the best mpeg encoder I know of.


Hi Sascha - Thanks for the TMPGEnc tip. I am trying it out as we speak (in the virtual sense ... speaking that is).

nice animations!


Thank you! These were just some tests for functionality. Absolutely no thought was put into their content. I have several untouched storyboards that I am currently in the process of choosing from for my first Jpatch project. I'll post progress once I have actually made some ... progress =>

It's difficult to animate arms or legs with morphs


Yes it is! That's why I put far too many keys into a motion at present to compensate for the "squish" that morphing does to a model durring morph animation.

I'm working on skeletal animation features to make animating things like walks easier in the future...


Very VERY happy to hear that. This will make things even faster (as well as more accurate). Any time line as to when a "bleeding edge" bones release would be available?

And yes, deleting temporary files was disabled by accident...


That's OK. I seem to remember that I was the one begging for rib file retention. They say be careful what you ask for ... well I got it. For the "Group" animation, the rib file generated was 4.6 MB per frame. That added up to 720 files for a total of about 3.3GB of rib files!

How about the shadow "on" tag for BMRT(Attribute "light" "shadows" "on")? Will this be an easy addition? Also, I previously posted a question asking if a text/integer string could be added to a specified location in the rib file generated.

Jpatch is really shaping up as a great tool for animation! I know that I will be contnuously putting it through its paces. Thanks again!

Robert
rjh
 
Posts: 179
Joined: Thu Dec 30, 2004 10:33 pm

Postby dcuny » Mon Mar 14, 2005 5:38 pm

Try these settings:
  • Mesh Density = 16
  • Supersampling Level = 3
  • Soft-Shadow samples = 0
  • Transparent shadows = false
  • Ambient occlusion = false
  • Max recursions = 7
Because it uses interpolated normals, Inyo can generate a smooth surface even at very low resolutions. The problem (like with bump mapping) is that you still get low-resolution edges:

Image

Note that these edges are rendered as black here, probably because the interpolation is giving it some negative direction.

If I could get Inyo do detect these "garbage" edges and make them transparent, I could actually increase the resolution of the model without increasing the poly count. This would have a bit of overhead (because you'd have to interpolate the surface normal at each hit), so there's be some overhead to it. Still, it's a tempting idea... :?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby pndragon » Mon Mar 14, 2005 8:20 pm

I changed the settings the way you suggested... there was no appreciable speed increase. The faults were all in the lighthouse model though... it was incompatible with inyo. Inyo apparently does not like cylinders within cylinders. I don't remember why I built it that way but it seemed like a good idea at the time. Rebuilding the model as a lathed object... the file renders in 26.297 seconds
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby dcuny » Mon Mar 14, 2005 8:31 pm

Hrm... You must have been using a slightly different version of the model, then.

This problem with refraction is an ongoing one with Inyo; I'll hopefully track it down at some point. :?

If you still have the old model of the lighthouse, would you do me a favor and do a test? Set the index of refraction on the glass to 1.0 and run a test, to see if it takes longer or not. That should help determine if the problem lies with internal reflections, or if it's just losing track of being "inside" or "ouside" the refractive material.

Thanks!
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby pndragon » Mon Mar 14, 2005 9:17 pm

With the old model and the glass index of refraction set to 1.0, the scene renders in 13.125 seconds...
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

PreviousNext

Return to Beta

Who is online

Users browsing this forum: No registered users and 1 guest

cron