I couldn't agree more...I feel the same way about the RPF export. I've heard similar sentiments from other users. How about a "QA before features" petition.. g

The patch didn't fix it? How hard can it be to fix that bug!

Have you tried renaming and starting the .eon cow?

Heh...it's funny how their patches are at a perpetual beta stage. Anyway, it was on the front page in that animated text thingie they got going. And it says beta now, didn't earlier. Oh well, now I can finally get some G-buffer rendering going, the one Pro feature I ever truly needed since buying it. Bleh.

Well, I'm a Combustion user myself, so I wouldn't know how AE handles it, but you should be able to set the offset and/or scale in the Z-buffer within AE. That way, you can 'push' the starfield behind the rest of the scene. As for the clouds, they will probably have a transparency channel, so that shouldn't be a problem. I'll try it out and get back to you.

The build is out now!
If you go to e-on's website, click on:
Support->Software updates->Vue4Pro->Get update

I have the same problem...I believe it's an old issue, but also an old pain! I once had to render a starfield as a texture onto a giant dome - it looks quite acceptable, even if it feels rather...dumb.

The new update (build 272334) may solve the flickering starfield issue, but if it doesn't (which wouldn't surprise me), it seems that it is now possible to render to RPF (Z/G-buffered) again, so a starfield could be rendered as a separate pass and then composited into the scene later. Of course, you'd need a compositing app such as After Effects or Combustion...

Oh, and you're right. There's no flickering when rendering on a single machine.

Hmmm...

Can you get a local rendercow up and running?
Are you running XP SP2?
Any firewalls?
You are running the beta patch? (Build 270996)

Attached Link: http://arwilk.dk/vue/Plum.zip

If you'd like, I could export a scene for you. I'm fiddling with it right now, wouldn't be any trouble.

Hmm...well, a couple of things - the synch plugin is not involved with the exported scene as such; it only works on cameras and lights. If you use the 'Export entire scene' function, remember to deselect the 'Export only selected objects' option (ahem). As to the grid, I click 'Decrease grid' 10-12 times.

You need to change the grid size in Lightwave. Vue works in a totally different scale, so you'll have to either scale the objects individually or change the grid size, which is what I usually do. If you don't, the objects will indeed appear to have vanished...they are still in the objects list, I hope..

Okay, I've had a chance to play around...syncing camera and lights from LW to VP works fine, but I've found that you should match the framerate and number of frames first, otherwise strange things can happen. Once the object's motion type is set to 'Synchronized' in VP, which it becomes when synchronizing, it locks the object so you can't mess with it. I also discovered that you can export any object animation as .mot files, which LW imports nicely.

Attached Link: http://www.e-onsoftware.com/Download/Updates/VuePro/SynchroPlugins.zip

I've just tested it, and yeah, it still works. The keyframe editor in Vue is rather flaky (3 crashes in an hour), but at least the synch plugin works. I'm rendering a 120-frame animation in FPrime as I type this. So far no problems, just remember to change the grid size in Lightwave. And if Vue tells you there's a new synch file available and do you want to load it, be careful - it just destroyed my keyframes.

I was referring to the RPF export, sorry. RPF is a depth-aware raster format which is used for compositing purposes. For instance, if I wanted a Lightwave character to move about in a Vue environment, I'd render the RPF sequences separately and use Combustion or After Effects to composite (blend) the two scenes into one. This is only possible with a depth-aware raster format. Therefore, it's quite a pain when Vue Pro won't export it, as I'm sure you can imagine.