Animator...

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

Postby pndragon » Wed Feb 16, 2005 12:59 pm

Try posting at The Renderman Academy. Those gentlemen are will probably be able to tell you the differences between the various renderers and what to do about it. Also Paul Gregory, founding father of Aqsis, cruises the forum there on a regular basis and made a posting there yesterday.
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby sascha » Wed Feb 16, 2005 1:29 pm

Try posting at The Renderman Academy

I didn't know that link. That's a good idea, thanks a lot! I'll wait a few more days and if I don't get a response in the Aqsis forum I'll try it there. Maybe someone could try to render the test-scene on a commercial renderer - I doubt that there is a problem with the file itself (it renders fine in 3delight and pixie, and the same data was used for the POV-Ray images as well), but who knows...?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

New test-version

Postby sascha » Fri Mar 11, 2005 11:28 pm

http://www.jpatch.com/temp/jpatch_20050311.jar

There are still some open issues, but since the "Render animation" feature finally seems to work I thought I put this online.

Open issues include:
* There's no "new file" option in the animator (to clear the current project).
* For the same reason, loading a file only works directly after the animator was started. If you want to load a new file, close the animator and start it again.
* Look and feel problems: Please use the Java "Metal" look and feel (you can set it in the modeler).
* Note that the preview playback (basically all the VCR control buttons) starts a new thread that performs the playback. Failure to stop playback before doing anything else will lead to arbitrary behavior of JPatch.

I've not yet added the options Pndragon suggested (to be able to set a different name for the rendered images), but I will for the next version.

In the animator, POV-Ray and RenderMan settings now include an environment-variable string. You can set the environment variables under which the renderer commands will be executed. The format is ATTRIBUTE=value;ATTRIBUTE=value;...

Please test the new "Render animation..." feature - It uses multithreading (to update the progress display and the stream output during rendering), and as I'm quite new to multithreading I'm not sure if it is implemented correctly. It would be interesting if it works as desired on a SMP multiprocessor machine...

Inyo renderings are now saved as PNG images and it uses David Cuny's ReadTiff code to read the tiff images RenderMan creates. I'll add an option that allows to save the rendered images in a different format.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Sat Mar 12, 2005 1:45 am

Here's a shot of all three renderers in medium/low resolution, side by side. Each only took a few seconds to generate:


Image
Medium/Low resolutions renderings by Inyo, POV-Ray and Aqsis of the same scene.

I'd have tried higher resolutions, but Inyo goes to la-la land when subdividing mesh at level 64 or above. I'll have to look into that. :(

From the placement of the lightlights on the eyes, it looks like they don't agree where the lights are. It looks like Inyo is placing the lights lower than the others. POV and Aqsis seem to mostly agree, the main difference being the size of the specular highlight.

I was able to render short animations of the character spinning around. POV is fast! The only irritant is that the GUI pops up. Could you add support for MegaPOV? It's got a console only version for Windows, Linux and Mac. However, it appears to require some tweak to the .ini file that I can't figure out. (If someone could tell me what that was, I'd appreciate it! :))

Inyo seems to render acceptably fast, with Aqsis coming in last, probably because (like POV) it has to load the file before it can start rendering. The uncompressed .avi files (generated with Bink) weigh in at about 12 Meg for a mere 48 frames of animation.

I'm having trouble figuring out how to get something to spin all the way around. Maybe it's the quaternions or something, but if I start at 0 and go to 360, JPatch seems to thing that nothing's moved. I can put in an intermediate keyframe at 180, but then JPatch interpolates a ease in/ease out at that frame.

I don't know what a good solution for that is... Anim8or solves this by allowing users to input degrees up to 720. A:M allows you to select various representations for rotations depending on what you're working with. :?

I'd still like to see JPatch show the frames "in process" as the various renderers are generating the frames, since that'll give render progress on a frame-by-frame basis. The other reason is because it'll show me where Inyo is falling down in the rendering. I added a glass sphere to a scene, and Inyo ground to a complete stop... :x
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Sat Mar 12, 2005 2:29 am

OK, I figured out why Inyo was choking: I wasn't launching it with enough memory! :roll: It can now render the scenes with higher geometry just fine - it takes about 4 times longer. I suspect it could be sped up a bit of the octree settings were tuned a bit. Something you can add to the Inyo API settings later, I guess.

That still doesn't solve Inyo's refraction code problem, though. I really need to find the problem. I thought I had made some sort of progress on it, but that's obviously not the case. It should only take about 6 times longer to render reflection and refraction, spawning a reflection and refraction ray as it goes through the ball. Instead, Inyo's just falling into a black hole. :x
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sat Mar 12, 2005 9:52 am

placement of the highlights on the eyes

Hmmm... I've seen the same in 3Delight. I fixed it by adding the "lh" (left-handed) ri-call after the camera. Perhaps the normals are the wrong direction. I'll try exporting them inverted, if it doesn't work check the specular code in inyo, maybe it's useing the inverted normals...

the main difference being the size of the specular highlight.

I think there's no "standard" formula for specular highlights, each renderer uses it's own implementation. There's even a difference between Aqsis and 3Delight.

POV is fast! The only irritant is that the GUI pops up. Could you add support for MegaPOV?

Just enter the path to the megapov executable instead of the standard povray...
To enable megapov-features you have to add a line like #version unofficial magapov1.1 or something. It should work by entering this line in the "include" textarea in the pov-ray settings, but I haven't tried it.
I'll have a look at those ini-files...
There's a cygwin version of povray that has the standard unix-like commandline interface. (Cygwin is a free unix-emulation-layer for windows).

POV is fast!

Yes, it is. The main reason for people complaining that POV is slow is that the POV-Team always priorized physical accuracy over speed, so there are only few "fake" features in pov - thus enabling photon-mapping, radiosity or subsurface scattering (they call it "media") slows down POV dramatically - together with the lack of some features this makes it less appealing for animation, which is a pity. But I think for "basic" raytracing, it's as fast as it gets, keep in mind that it has evolved more than ten years as an open-source renderer. With a few exceptions (e.g. complex CSG objects), bounding in POV-Ray seems to be very efficient. I've little expirence with C so I have difficulties understanding the source, but maybe Inyo could profit from "stealing" some POV code ;-)

Aqsis coming in last

That's true, but it is a new renderer so I think there is space for improvement. Keep in mind that oversampling in REYES is not adaptive, so by setting it at 2x2 it really renders 4 times as much. You could lower the shading rate, but that would decrease image quality. 3Delight is much faster. But you can't really compare raytracing with REYES.

I'm having trouble figuring out how to get something to spin all the way around. Maybe it's the quaternions or something, but if I start at 0 and go to 360, JPatch seems to thing that nothing's moved. I can put in an intermediate keyframe at 180, but then JPatch interpolates a ease in/ease out at that frame.

Well, first, if there is one keyframe at 0 degrees and the next one at 360 degrees, JPatch recognizes them as the same, so the object won't rotate at all.
Now if the object in the next keyframe faces exactly in the opposit direction (e.g. first 0, then 180 degrees), how should it know around which axsis and in which direction it should rotate it? So you need at least 3 or 4 keys for a full turn: e.g. one at 0, 90, 180, 270 and 0 degrees.
Note that the velocity of the rotation is not interpolated correctly because I don't yet use spherical interpolation.

Anim8or solves this by allowing users to input degrees up to 720.

I think that isn't possible with quaternions. I could add euler angle representation (roll, pitch, yaw - right now the're converted only for the display and numerical input, internally it uses quaternions), but they have other, more serious problems: E.g. try to roll the camera over the zenith without quaternions...
Another drawback of the euler-angles is that if you interpolate them directly, the object or camera would not rotate along the optimal path: Imagine a map of the world - the shortest way from e.g. London to New York is not a straight line (that's why they fly over Greenland), but that's what the euler-angle interpolation would do. Spherical interpolation with quaternions solves all that, so I think it's the way to go...

I'd still like to see JPatch show the frames "in process" as the various renderers are generating the frames

Can your tiff reader read partial images? The png reader can't :? But we could add that for Inyo of course - maybe and int[] array of RGB values per scanline...
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Sat Mar 12, 2005 10:23 am

I don't think there's any "partial" image to read. It appears that both these programs write out a complete version of the file every couple of scanlines, so you can literally watch the image as it's being rendered.

Inyo used to wait until the image was complete before rendering it into an Image, but that's no longer the case - it now creates a blank BufferedImage, and renders directly into it. Calling RtCavas.getImage will get you the BufferedImage, so you should also be able to watch it dynamically.

Probably the simplest thing to do would be to add a BufferedImage property to RtWorld called canvas:
Code: Select all
BufferedCanvas canvas = null;
It would be set by RtRaytracer:renderImage:
Code: Select all
public Image renderImage(RtWorld world) {

    ...

    // create a canvas to store the image
    RtCanvas world.canvas = new RtCanvas(world.width, world.height);

    ...
and change the remaining references of canvas in that routine to world.canvas. In RtInterface, you could add the function:
Code: Select all
   public BufferedImage getImage() {
      return world.canvas;
   }
That would pretty much do it. You'd want to make sure you didn't get a null value back before you started rendering. ;)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Sat Mar 12, 2005 1:48 pm

By the way, I found the "problem" with Inyo - the half the normals on the glass sphere were flipped around the wrong way. I had fixed this on my home machine, but not my work machine, where I rendered the animation.

It seems to me that JPatch could have an automatic "fix normals" option, by comparing the normals on a patch to the one next to it. For the most part, neighboring patches should have their normals aligned. I guess folds would be the exception there... :?

If you ever implement a face selection mode, it'll make it a lot easier to select faces that need their normals flipped.

Anyway, I'm just happy the code didn't "magically" revert back to some broken state. :D
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sat Mar 12, 2005 6:53 pm

I've tested it on Windows:

* Aqsis 1.0.0 works fine with JPatch.
* The official POV-Ray 3.6 version works fine, but pops up the GUI on each invocation (there's nothing you can do about it)
* The console version of MegaPOV 1.1 works fine. You can download it from here. In The POV-Ray tab of the Render Options enter the path to the MegePov executable and set the version flag to "Unix/Cygwin"
* I can't get 3Delight running with the licensing server. The TIFF images made with the demo version (with the watermarks) can't be loaded by the readTiff :?

I'd be curious if it works on Mac OS-X...
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby rjh » Sat Mar 12, 2005 8:37 pm

Hi all,

I've done some preliminary tests with jpatch_20050311.jar using BMRT. RenderAnimation now works fine - thanks Sascha. However, the "Delete per-frame files after rendering" no longer works. Checked or un-checked the rib is not deleted after rendering. It worked with the jpatch_20050308.jar (loded it back up and tested checked and un-checked). I also could not find a way to turn the shadows on (Attribute "light" "shadows" "on"). Have you added this yet Sascha, and I just cannot locate it?

For the animation imparted via the morph targets / sliders, this is very well implemented. I have not yet tried any rotational tests yet, but they are next on my list. I'll put some links up to the initial test animations (simple walk cycles) later tonight or tomorrow.

Great work Sascha.

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

Postby rjh » Sat Mar 12, 2005 8:42 pm

BTW - what would be the best format to publish for viewing with Linux? AVI (currently I use Indeo 5.1 and Xvid compression for AVI)? Quicktime? Another format that I do not know about? Let me know please ... I would like to reach the broadest audience.

Thanks in advance!

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

Postby dcuny » Sat Mar 12, 2005 11:36 pm

The best format in .mpg - never a problem playing them on any platform. This is, unfortunately, the most complex format to encode, and doesn't appear to be supported by the Java Media toolkit. :(

I can run some .avi files, but for a lot of codecs there's no official release for Linux, so it's problematic. Uncompressed .avi will play back, but those files are massive.

Quicktime has similar issues: I can typically play it back, but typically without sound. I haven't tried any files created with Java Media, though.

So for a single file format, .mpg is probably the best bet.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Sat Mar 12, 2005 11:52 pm

Under Linux, POV-Ray and Inyo work just fine. POV-Ray's output seems a bit verbose; if there were a way to display a bit less information, it might save a second or so.

I can't get Aqsis to work - it segfaults on me. :?

As I mentioned yesterday, all three renderers worked fine for me under WinXP. :D
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby pndragon » Sun Mar 13, 2005 5:28 am

On WinXP and Win2000 I am getting nothing from Inyo and BMRT... 3Delight, Aqsis, POV-Ray, and Mega-Pov are fine
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby dcuny » Sun Mar 13, 2005 8:56 am

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.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

PreviousNext

Return to Beta

Who is online

Users browsing this forum: No registered users and 1 guest

cron