First of all, thanks to forum members who were kind enough to answer some of my questions about Vue 5 Pro Trial edition. Think I might go for Vue 5 Pro. So, guys and gals, honest answers please.... Is it reliable, does it crash, does the Poser import work satisfactorily, are product issues patched quickly, is support responsive to your needs, do some features simply not work properly. How many patches have there been since release, what are the real bug bears at present (I gather a memory leak is one of them). I don't want any nasty suprises....

You should clarify first, if you refer to Vue Pro Bundle (which is an Esprit on steroids), or to the full-featured Vue Infinite. Anyway Poser 5 import is excellent and very solid. Poser 6 still has some problems and is still being worked, but that's because Poser 6 came out after Vue Infinite did, so it's normal. As for support, I always had an excellent one from E-On when I needed it (which rarely happened). As for the features not working properly, yes there are a few bugs here and there in the release version of Infinite, but that is absolutely normal for every application's first release nowdays. A major bug fix patch is already in the works and should not take much to be completed i think.

As for the memory leak, as experienced for instance in older versions of Esprit 5, or in the early betas of Infinite 5, it is gone (as far as my installation is concerned) or very much reduced (according to the less positive reports), but in any way, it should not be a problem anymore. I read of tests made recently, and to make Vue Infinite crash now you need to employ a simply ridiculous number of objects and polygons - a number that, by the way, would make crash almost any other 3D software of today.

I can't speak for Poser importation, but I can tell you my experience with Vue 5 Infinite has been satisfactory. Overall, at this stage of patching, I'll give it a B-. There have been two patches for Infinite since I purchased the product a little over a month ago, and the software's memory management is still an on-going issue. For the Mac users, the issue is less eveident with the newer build, but the PC users are still complaining. If you visit the Vue forums at e-on, you'll see this is the case, but unfortunately, you can't view the forums unless you've purchased and registered an e-on product. But trust me, the complaints remain. I bring my PC to its knees with a polygon count approaching 1.5 to 2 billion, but can still manage a render. Above that, I'll crash 50% of the time, below that, say 500 million, software performance is reduced dramatically. With that said, I still enjoy using the software, I just have to be aware of what's going on in the worlds I create as well as tweak the software a tad. Using billboards helps tremendously (learned that here). If I keep an eye out on resources, I rarely crash. I'm not aware of a "major bug fix patch" but I do know e-on is well aware of the memory/performance issues of Infinite on the Windows platform and would guess there will be several more builds before most of the issues are addressed, just like Vue 4. Vue 5 Infinite is their flagship product, no doubt it's high-priority. E-on's customer support is top notch, IMHO. If I might add, while $200 is quite a bit more for the Infinite product, it's well worth the extra expense. Somewhere on the e-on web site is a comparison page between the products. Compare between Esprit, Pro and Infinite and you'll see what I mean. Bottom Line: I recommend Vue 5 Infinite to anyone. It's a fantastic product and well worth the investment. BTW, my recommendation would be 2 gigs of fast RAM, no matter what e-on says. The more the merrier with Infinite.

I still have memory problems, but I'm not using the latest beta patch (Orio, what patch version are you using?). I have 3.6 GB of ram, which is more than Vue seems to use anyway, so lack of ram's not the problem. The V5Infinite Ecosystem is awesome! Definately worth the price difference over V5Pro. There are other extras as well, but just the ecosystem alone makes it worthwhile. I've gone to nearly 4 billion virtual polys without any problems other than slow down. Where I run into memory problems is with 'real' polys (such as the Xfrog models used for the ecos, and Poser figures). If I subtract the native Vue polys, such as the terrain, memory problems hit at a little over 1 million polys. And that's using reduced texture resolution. Texture resolution also plays a big rule in my memory limits. Summed up, ecosystems work incredibly well if you keep the input under control! Just be careful what they're based on. Memory problems or no, I still think Infinite is the way to go.

hi Steve, I have installed the latest beta as always. Vue has this very neat possibility of reverting back to the previous installation, so it's never a problem to test betas. Only care is, before you install a new beta, uninstall the previous one i.e. revert back to original installation. I have tested Infinite with big landscapes but never got into problems with memory. But I have to say, that I am very careful about the use of resources in my landscapes: 1) While I work, I usually hide layers that are not useful for the part of picture I am working on. This saves a LOT of troubles and also makes arranging the scene much faster. 2) For every scene that I make, before I even start, I create a folder, and save all the models and textures there. Until I make tentatives, I usually don't care about the textures, because the scene is in the early stage and memory is not a problem then. Later, when the scene is more advanced and I have made my final decisions about which is going to appear where, I always resize down all the textures (which 99% of cases means Xfrog and Poser textures) of those objects that will not appear in the foreground. A 512x512 texture size is more than enough for a mid-ground object and a 256x256 is more than enough for a background object. 3) another step is to save all foreign objects of my scene into Vue format, and reload them into the scene as VOBs using the very handy replace function. Vue seems to "like" handling VOB objects a lot more than foreign objects. 4) Finally, for all real background stuff (distant trees or crowd a typical example) I always use billboards, which I make myself in Cinema 4D using the same frontal rendering setup that we use to produce the billboard panels at Greenworks. There is really no point in "ecosysteming" real 3D objects at faraway distances. So the nutshell of this last point is: use 3D objects in ecosystem only for your foreground or important mid-ground. Unless one is in for beating some Vue rendering record, it won't make any real difference to a picture.

Thanks Orio for some steps I can take to reduce memory usuage. I think textures is my culprit; as I have 2 GB RAM and even with only 300,000 polys my scene can crash Infinite. I am using hi-rez textures though. I'll have to try and reduce them and see what happens. Of course, it goes without saying it crashes Poser 6 as well!

Hi Orio, my Xfrogging friend (wow, quick response!). I gotta agree with some of your tips, but I'm getting different results in others. I haven't explored the reverting option you mention, but haven't needed to. V4 was aweful for updates, but V5 has been doing very well (for me, at least). 1) I usually don't use this one until I have to, but DO use it. 2) I use a similar approach. As soon as I install something new that includes textures, I make reduced versions of those textures. I move the originals to their own folder so I can keep the same file path and name in Poser or Xfrog for the reduced maps. This avoids the remapping hassle. Very good point! Something we all should do (and maybe vendors should take note?) 3)Yep, started doing the vob save routine in V4Pro. It most certainly helps, but not enough. 4) Now this one is something I don't like to do, unless I absolutely have to. In V4, I had to. With ecosystems, it doesn't seem needed... at least for me. The only time I run into memory problems with ecosystems is if the base objects amount to too many polys or too high a mat resolution. For example, I tried an eco that had around 15 imports. The problems I had were not because of the ecosystem itself, but because V5I couldn't handle the 15 objects. In other words, if I were to place those 15 objects manually... without any ecosystems.. V5I still couldn't handle it. It was the number of real objects that created the memory problem. Like I was saying, ecosystems themselves seem to handle memory very well. V5 in general doesn't seem to like a lot of stuff. You know, this would be a great subject for a seperate post. A lot of people seem to have problems with memory in Vue... no matter what version. We need a memory tip collection. Or does one already exist that I missed? Either way, many thanks buddy.

"1) I usually don't use this one until I have to, but DO use it." Well, of course every person has his workflow and experienced users like you always developed over the time the workflow that suits them best. But for beginners reading this, I would like to reinforce this point. Don't under-rate it's importance. I have the feeling that what is experienced as memory leak is really Vue having to cope with too many large textures, refreshing them after every action, and trying to keep them in memory as long as possible in order to improve the performance. Perhaps a little bit too long. But if I am right in my guess, then this is something that we users have some control on, not only the programmers. By hiding unneeded layers during scene preparation, we spare Vue the taks of keeping in memory large chunks of bitmap data that we dont really need at the moment, and re-reading them every time we adjust the scene. This does a long way for preventing the much feared "accumulation" problem. Call it "safe vueing" if you like :-) It is possible that also turning preview of object into wireframes might have the same effect without having to hide whole layers. I find that turning on/off wireframes quite tedious so I generally prefer to hide a whole layer alltogether.

Another old-fashioned trick but I do never get rid of an old horse if he can still walk his mile ;-) so beginners may be interested in learning this. IN old 3D times, practically all of us used to build complex scenes by use of placeholders. I made myself some then: spheres on cylinders (in various shapes) for trees... the same for people, in different proportions of course! For all geometrical objects such as cars, combinations of boxes. If you build a few basic ones and save them, you can reuse them in your work. I assure you that if you take a little care in building them (like: make a round sphere for planetree crown, a stretched sphere for cypresses, etc.) it is not that bad. Oh and one very important tip which I forgot before! Start your scenes with all your terrains at 256x256. Turn them into higher resolution only when you are ready for render, and don't do that if you can avoid it: many people often blame heavy polycounts on vegetation elements, but I grant you that a couple of hi resolution terrains can weight as much as a dozen trees in your scene.

I forgot to add that placeholders use is extremely handy in Vue infinite, because you can replace them with a single click operation! And - Vue Infinite offers a built-in and more evoluted version of placeholders: it's the decimated objects. You can decimate an imported object into the Vue scene, in order to reduce it's polygons size, even dramatically. Of course, it will look bad (or not as good); but, you don't have to keep it forever: when you are ready for render, just replace it with the full featured original, that you have wisely kept (did you?) ;-)

Very much appreciated!

Yeah, that decimated tip is a good one. Just started using that recently. Sometimes I can decimate quite a bit, and the figure still looks good enough for final render.

Funny thing about those placeholders. In Vue 4.5 Pro, I ran into some nasty saving crashes when using 10 or so hires Poser figures. But by replacing them with a couple of simple untextured boxes I could manipulate the scene fast and fine. Just before the render I replaced those boxes with the Poser figs (saved as VOB). Render went fine, saving was impossible. So using placeholders is definitely a good idea. I haven't had to use them in Vue5Inf yet, but I'll keep the trick in the back of my mind.

"In Vue 4.5 Pro, I ran into some nasty saving crashes when using 10 or so hires Poser figures." well, that is clearly on the limit of the possibilities of today's home computers. It's important to point out that any 3D software, not just Vue, will have serious problems handling 10 high resolution Poser figures. "But by replacing them with a couple of simple untextured boxes I could manipulate the scene fast and fine. Just before the render I replaced those boxes with the Poser figs (saved as VOB)." Yes, that is definitely the way to go when a scene is so much busy. "Render went fine, saving was impossible." Well, as long as you keep the poser figures in a folder together with the Vue scene, and a txt note of what replaces which, you can also save the scene with the placeholders and, in case you need to re-render, just re-replace them with the poser figures. Not ideal, but possible. The best solution IMHO would be to decimate the Poser figures that are distant (if there is any)

That saving issue is a real bug. I monitored memory usage during a save, and (depending on scene complexity) Vue 4.5 Pro required between 15 and 200 MB extra for just the save. It also happens in scenes containing only native Vue objects (terrains, rocks, trees, and not a single VOB). I've reported this bug to e-on a couple of months ago. Vue 5 Infinite does not have this bug. By the way, noting what replaces which is not necessary when you give the VOBs a useful name, and use that same name for the placeholder in the scene. And I always create a new folder for a new project. I use multiple pz3 files and often some "loose" .OBJ files (made in Max). I found that it's usually better to convert those .pz3 and .OBJ files to VOB one by one, restarting Vue before importing the next file. Vue 4.5 Pro has lots of trouble releasing memory, and again Vue 5 Infinite works much better - but not flawless. In short, I'm very happy with Vue 5 Infinite. Definitely worth the money.

Attached Link: http://www.gerhard-mantz.de

Yes, Vue 5 inf is a very nice toy. Its fun to have all the tools and to finetune a scene with hundreds of adjustments. I just cant stop me from playing around. Unfortunately as a professional I cant use it, because the render engine is a mess. Just try to render, say one of their example files on the second cd in a decent resolution, like 14000 x 8000 and you see what I mean. I can handle the frequent crashes while building up a scene. I learn what to avoid the bad things and work around, but have no work around for the memory problems in rendering. In other applications you can tile an image, render parts and combine them in photoshop. Not vue. Bryce can render complex scenes with tons of imported xfrogs or posers without filling up the RAM. It is possible. Best, Gerhard

Vue 5 Infinite can tile render an image, either on a single machine or on a render farm. I've rendered one of the sample images on a 4 machine farm as 4x4 tiles. Works fine.

Sounds good how big was the image and how much RAM have you installed. On my computers rendercow immediately quits when you try to give her more than 6000 pix.

Rendered ad 3200x2400px. Main machine has 4 GB, one machinee has 1.5 GB, the two others have 1 GB. Disk speed is quite important, the slowest machine was my portable, P4 2.66, 5400 RPM disk, my P4 2.8 with 1.5 GB/7200 RPM was twice as fast, my Athlon2700 with 1 GB/ 2x7200 RPM RAID0) was a little faster than the P4 2.8, and the Athlon64 3500+/4 GB, 2x 10,000 RPM RAID0 was twice as fast again.

Thanks for the answer! Ok. 3200x2400 does my computer also. 2GB RAM 2.6MHz Pentium 4. I need images to blow on 4m, means 17000x10000. Problems begin at 10000x6000. But listen you say one machine has 4GB. Does windows xp support more than 2GB? You think I can upgrade to it? Best, Gerhard

Windows XP supports 2 GB per process. Having more than 2 GB physical RAM means the application (in this case, Vue) can claim a full 2 GB of physical memory, while parts of the OS, parts of other processes can remain in memory. Most important is the system cache - that speeds up your drive access. With more than 2 GB of physical memory the system cache remains pretty large, keeping the system up to speed. So upgrading can help, especially for those large size renders that claim a lot of physical RAM. Windows 64 bit is about to be released. That version supports 4 GB per process, even in the Win32 subsystem. I'm not sure whether Vue will profit from those 4 GB though.