This is exactly how depth cuing is supposed to work. It has been a feature since P4 (at least) and does still work with the P4 renderer in P5. In this respect, the manual is incorrect where it says that says that it shouldn't work in renders. Unlike you, I can't get it to work in Firefly, but (due partly to popular demand), depth cuing settings were added to the atmosphere node in the material room in one of the SRs. Bill

... and furthermore, never, never give the customers the impression that you assume they are idiots. As a matter of interest, _digger joined only a few weeks ago and his only previous post was, to all intents and purposes, an inquiry into the potential size of the Poser market. I may well be wrong here, but I'd certainly stake shed loads of cash that there is indeed a direct connection between himself and posertoolbox. andrejacyshyn could well have been forgiven the first post on the grounds of ignorance, but this post is a deliberate charade. Not withstanding the grey areas in the definition of advertising, the ban on ads in this forum has arisen from the wishes of the members. Merchants who antagonise members of their customer base by flaunting this are wholly missing the purpose of promotions. Even without the TOS, true professionals would stick voluntarily to the Product Forum simply because that's what the customers want. As far as the product is concerned, this kind of thread will give nobody any confidence in your ability to deliver and support professional software. Bill

In fact even stray vertices which are not associated with any polygons can do this, which is something of a problem, since they are effectively invisible within Poser. Bill

If you are using P5 with your background square or sphere prop you can plug the background image into the ambient channel, set the the ambient value to 1.0 and then set the diffuse and specular channels and values to black or zero. This way the background won't pick up any shadows or any other artifacts due to the scene lighting, and all the illumination will come from the image itself. Bill

People had problems with V3 when they installed the injection file directiory into the P4 libraries, but tried to access from P5. Apparently it's the P5 runtime linking that causes this problem. It should be solved if you copy the !DAZ folder from the P4 Runtime library folder to the P5 library folder. Bill

Attached Link: http://graphics.cs.uiuc.edu/~garland/software/qslim.html

Firefly probably doesn't, but, as its a component of a 32 bit application, it is limited, like all 32 bit applications to 2GB. This is because, a 32 bit word used to store a memory address can only really represent 2 to the power of 32 distinct numbers (adresses). This is actually 4GB, but the operating system also need to reserve some of the application's memory space for their own interfaces, and most operating systems (Windows, Mac, Linux) just split the 4GB range down the middle, allowing 2GB for the program to play with. Many of the crash type problems I've seen seem to occur when people top the 1.7 GB mark in Poser. It's possible that temporary allocations are nudging the memory use over the 2GB mark, without it ever being registered by the Windows task manager. Bill

I believe Zygote still sells some of the stock P3/P4 figures in different file formats for use in other 3D apps. Its possible that the makers of this video actually paid exhorbitant prices for the meshes without ever using or being aware of Poser. Bill

*A main reason why no third party has developed a plug in is that the Bryce .br5 format is not only undocumented, it's even encrypted! (So I'm told.) * It isn't actually encrypted, it's just in a binary format and much of the implementation is pretty unique. Bryce has basically followed a parallel but seperate evolutionary path over the years from most other 3d technologies. I pretty much have nearly complete data on the br3/4/5 file formats, so file convertors are definitely on the cards (it's on my business plan). However, the additional work required to achieve a full (live) data sharing plug-in is economically more questionable, and there's no data yet to indicate whether the Bryce API meets the basic requirements for such a thing. All we can really deduce from the existing im/exporter plug-ins is that the API supports the ability to add and extract data, which by itself is not sufficient for such a plug-in. Bill

• There are also a couple of good books on RenderMan which should explain the principles behind these kind of renderer * Just to clarify that Renderman is not actually relevant as it is an interface definition/file format. Confusion is common as both REYES and Renderman were developed in unison by Pixar, and the basic functional requirements Renderman compatibility are, for this reason, very much biased toward the capabilities of Pixar's own in-house REYES implementaion PRMan. However, on the whole Renderman is intended to be(technological) implementation independent and there are Renderman compatible renderers the use non-REYES (e.g. RayTracing) techniques. Stefan is right though that the basic technology is based on the REYES (the engine was acquired from Pixels Digital). However, Firefly is a fairly poor example of the REYES principals, one of the cornerstones of which is ultra-low resourse usage. It was on this principal that much of the implemention was designed and choices were selected in the REYES spec. Low resource use can always be traded against image quality and performance, which has lead to REYES being the foundation of most modern rendering solutions, and the tool of choice for the vast majority of animated features. In implementing Firefly, despite its likely pedigree, CL have unfortunately managed to breach this principal by attaching it to an extremely resource hungry front-end. The result is a typical programming bottleneck, or if you like, something like harnessing a pedigree racehorse to a plow. Poser just cannot serve resources efficiently enough to allow the full potential of the rendering technology to be seen. Bill

The conceivable adress range is 4GB for a 32 bit word, but also some of the address range needs to be put aside for OS services, etc. and typically all of the major OS's simply split the address range down the middle, so that there's an upper and lower range, split at the 2GB mark, one half for services and the other half the (allocatable) data heap. So far as I am aware this applies to all Windows Mac OS's and UNIX brands. The only exception that I'm aware of was an enterprise version of NT which allowed 3GB for program data, so at least there is maybe some flexibility. At the end of the day though, OS developers really aren't interested putting in the work to allow more space for application data because there simply isn't any compelling reason as to why any program should need anything like 2GB of memory in the first place. Bill

the OS handles all memory aperations at 64 bits, thus improving performance for memory intensive applications. Unfortunately, the memory limit is neverthess compiled into the code of 32 bit applications, and regardless of the underlying OS memory operations, the numbers embedded in the data just basically can't refer to addresses with ranges greater than 2Gb. The next generation always will always, of course be faster and have a better performance for a number of reasons, and quite likely, with a "real" 64 bit bus architecture, data movement will be substantially faster, and page faults reduced, but the 2GB limit won't go away. Its unlikely that any real performance comparisons will directly be relevant to Poser, though. For the vast majority of applications, including those that likely comprise the benchmarks, 2GB is considered to be more than enough memory that any developer needs to implement anything. Even compared with "heavyweight" applications, Poser's memory usage is astronomical. As I've said, DAZ|Studio doen't need to 64bit to achieve greatly more capacity than Poser, all it needs is for the developers to be aware of resource usage and make sensible choices. Interestingly, since DAZ have already sussed out that they needed disk buffering, aka. Morph Injection, to make V3 practical, I suspect that there's a great likelihood that they will be (trivially) automating this in Studio, which by itself will reduce the memory use for figure by a significant factor. Beyond this, if they handle the RSI material capabilities of the 3-Delight renderer according to the book (again with disk storage) the memory requirements for texture maps will effectively disappear. And of course, a Reyes renderer architecture (ignoring Firefly as a bad example) technically only needs one polygon, one pixel and a render bucket stored in memory at one time. If anyone's running a tab, I'd be putting money on Studio having (effortlessly) ten times the "raw figure capacity" than P5. But will OpenGL be able to handle the load?? Bill

Unfortunately, Poser's only a 32 bit application on both the MAC and the PC, so regardless of what memory you have installed on a 64 bit machine, P5 will only ever be able to utilise a maximum of 2GB data space. Basically, once its assigned half of its memory range to the program image and OS interfaces and other system stuff, that's the total range of addresses is capable of represnting in a 32 bit word. Even if it were to survive for another release I suspect it would probably still be several years before we actually saw a version that was capable of running in as a native 64 bit application, and therefore being able to exceed the 2GB barrier. I've gone into this a lot in the past, but the upshot was that P5 was pretty much obselete when it released, there were already plenty of signs that P4 users were getting close to the maximum capability of the (32 bit) software, and it was no stretch to see that the next generation of DAZ figure were going to push things even further (ergo morph injection, a kind of manual disk buffering). Not to mention all the new functionality which squeezed the envelope even further. Not that any of that really matters, since, with a better design, Poser could probably effortlessly running at less than 100MB so far as anything that people are actually managing to do with it. There is incredible inefficiency, literally 90-95% or more of the memory use is wholly unnecessary. Maybe, Poser 6, if there is one, or maybe DAZ|Studio will give us an application actually raises users expectations off the floor. Bill

As the above, it wont work with "true" morphing, that only changes the mesh, not the joint setup, but it should certainly be possible to use channel linking techniques to create whole figure height dials, ie. contol multiple scale changes through one parameter. The place to look for this sort of information is the Poser technical forum. You should probably search a few threads, since their has been plenty of past discussion, research and analysis of this sort of thing. Bill

urrr.... the creative poser of Poser ...should be... the creative power of Poser Slaps head Bill