Deep Exploration requires 3DS Max installed in order to open max files, and it actually uses 3DS Max to do the opening, then transfers the in-memory data out of Max and into DE in a Right Hemisphere format. From there it can save in other formats. Basically, it does this by acting as a Max plugin.

The 30 day trial period really just applies to the version of Deep Exploration that ships with the Free version of Enliven. It is a real time limited demo, so after 30 days, you lose the extra file format import options that DE provides, unless you already own or buy a license to DE. However, the free version of Enliven will continue to function and correctly sign Viewpoint content even after the 30 days are up.

You don't have to buy it after the "trial" period is over, although the version of Deep Exploration that comes with the free version is a real time limited demo so after the trial period, you lose the extra file import options that DE provides unless you buy or already own a DE license. The free version of Enliven will keep working and will correctly sign Viewpoint content even after the "trial" period is over. Enliven does embed IE, sort of like Poser does. However, in Enliven, the purpose of the embedded browser is actually to preview the content you've created using the real browser and VMP plugin, before hitting the "Publish" button. The content created in Enliven should run in quite a few browsers, and work on Mac and PC.

I have to agree with a lot of folks on this thread about the foot closeup. While I think it possible to narrow the original foot a bit, the GJ foot simply does not look like a human foot. If something that extreme is absolutely required in order to fit into open-toed high heel modeled shoes, at least make it the extreme of a dial-able morph. Or work on the shoes...

bluetone is correct about the E: drive. It is just giving the full path at the time Carrara was built to the source file in which the exception occurred -- the drive structure on the build machine is all the compiler knows about at build time, so that's what shows up. This information is useful for copying into an email to Eovia support (that's why messages like this are left enabled at all), but is not particularly useful to the end user. -Jeremy

I know the Viewpoint licensing structure has certainly been impractical for individuals and small companies. You might want to keep an eye on them during the course of this year. As you point out, the technology is quite good... -Jeremy

Poser can also export to Viewpoint format, which is a real-time 3D format for the web. Your model and animation is still in 3D, so it can be a little less pre-scripted in terms of animation, camera views, etc. Still have the problem of generating the speech if you have dynamically generated text you want the avatar to speak, though. I have built some natural language conversational agent technology, and have considered tying it together with a 3D avatar like this, interacting through javascript. Too many other software dev projects to keep me busy though... -Jeremy

Regarding the path given in the error message you show above, that path would actually be the path to the source file that the exception occured in on the machine that Carrara was built on at Eovia. So it is not your E: drive that it refers to. That path is the only one that the compiler knows when building the app though.

I think it is worth adding OpenGL preview as an alternative to the SreeD software renderer, but people should keep in mind a few limitations. First, this would be a realtime preview system, and would not affect final render times. Rendering engines for final images are nearly always software engines. Graphics cards are not architected for doing things like raytracing. Although there are some experiments out there in trying to offload some raytracing math onto GPUs, there isn't much beyond experimentation happening on this front. OpenGL cards could probably generate a render as good as the P4 scanline renderer, but its not going to do everything that firefly or another hybrid raytracer is going to do. Also, regarding speeding up the preview display, OpenGL acceleration will speed up rotation, translation, etc., of fixed meshes, and certainly camera view changes. However, posing (where you are actually changing the displayed meshes) will probably not see as large of a speed boost. All that said, I think it's still a good thing to add as an optional display mode.

I must disagree. QSA does not provide the application framework. QT provides the application framework. QSA is a scripting language very like JavaScript (based on the same ECMAScript standard that JScript and JavaScript are based on) or Python. The QSA interpreter can be embedded in a C++ QT-based application just like the Python interpreter can be embedded in a C++ application. QSA happens to provide bindings to the QT objects and their methods, so you can create QT-based UI from within scripts. PoserPython is slightly different in that it exposes the Tk UI toolkit instead of Poser's underlying UI framework (except in Poser 5 for the Mac, where some of the underlying UI framework is exposed because of the problems getting Tk working with Poser on OS X). Check out http://www.trolltech.com/products/qsa/index.html for more on QSA and embedding it in a QT-based app. I think it is possible to run QSA through a standalone interpreter and build simple applications that use QT for UI by linking with the QT libs, as you can do with Python and a number of UI toolkits (TK, wxPython, etc.) I'm sure DAZ has not done that, however. The mesh deformations required for posing cannot be done by the graphics card alone through OpenGL. Although you can offload some of the matrix math to the GPU, the CPU still has to do a lot and a scripting language is just not going to be fast enough. D|S is a pretty complex app, and writing and maintaining such a thing in a language as unstructured as QSA would be a development nightmare. Finally, D|S will have a C++ plugin architecture, which is not something you want to try to build into an app written in a scripting language. Not a big deal -- I just think you have misinterpreted what Rob said in the thread over at DAZ. I am not a DAZ cheerleader, just an interested engineer. -Jeremy

I believe that QSA is an end-user scripting language which can easily be built into a C++ app built on top of the QT cross-platform application framework. Think of it like Python in Poser, only its a different scripting language, in which the end user can write scripts to extend or customize the underlying application. I've not actually built anything in QT, but have investigated it as a development framework (before choosing wxWindows instead). QT is a C++ development system and QT-based apps are written in C++, so the main body of D|S would be written in C++. As to the question of compiling it for a 64 bit system, however, that could in theory still present a bit of a challenge, since that sort of depends on QT successfully compiling for a 64 bit architecture, as well as the dependency on 3Delight noted above.

Message edited on: 06/02/2004 17:42

Hey Anthony, how's it going? Long time no hear, after the 2002 layoffs :( Hope all is going well with you and your family. Good luck with the Poser book. That's cool -- I think a workflow-formatted book is definitely needed for P5 and going forward. Many have said the basic things I would imagine being covered. I would place some emphasis on the materials room. It is actually a very good procedural shader network system, and I think that 90% of folks are probably only scratching the surface of what it can do. Take care, Jeremy

As who3D indicates, the memory bottleneck is one of the biggest performance hits in any machine. This is particularly true in graphics apps, which tend to be very memory hungry. Instructions are executed in pipeline in a CPU. The number of pipeline stages varies between architectures, but a grossly simplified version is something like: fetch instruction, decode instruction, fetch data, perform instruction, store data, update program counter. Each stage will take some number of clock cycles. Modern CPUs can execute multiple instructions at once because they stagger the instructions by pipeline stage. When the first instruction moves from the fetch to the decode stage, the next instructon can enter the fetch stage, and so on. Thus, the more deeply pipelined the architecture, the more instructions can execute at once. However, sometimes a stage like fetch data can take a LARGE number of clock cycles because of the relatively slow access to memory. When this happens, the entire pipline will wind up stalling until the fetch is completed and that instruction moves on to the next stage. This a major reason that CPU makers try to squeeze larger and larger on-chip caches onto CPUs. The cache stores the most recently accessed data, so that hopefully the next time the CPU needs a piece of data, it will be in the fast-to-access cache and the CPU won't have to go get the instruction from main memory. Generally, a system has multiple caches, organized in levels. The fastest to access are the smallest, and they get progressively larger and slower to access. So, there may be up to 3 levels of cache before you get to main memory. Unfortunately, most people's use of modern graphical applications overwhelms on-chip (and even off-chip) caches pretty quickly, so there is a lot of main-memory access. This is where algorithm designers can do a little to help. If you can design algorithms that have good locality of memory access, then caches will help more. In graphics apps, you are still going to have to access much more memory than will fit in a cache. But if you have multiple operations to do that will hit a particular memory location, you want to try to design an algorithm that will do all those operations at once to each piece of data, rather than doing one operation to all the data, then the second operation to all the data, etc. For example, in 2D image processing, suppose you are performing a simple emboss operation and converting to grayscale. You could do that faster by iterating over all the pixels in the image and for each pixel, calculating RGB values for the emboss operation and the grayscale operation, rather than iterating over the pixels twice and doing the emboss operation in the first pass and the grayscale operation in the second, for a number of reasons. One, you will not have the loop overhead twice, but more importantly, you will probably have to load each pixel's data from main memory only once instead of twice (assuming the image is larger than will fit in the cache, of course, which it likely is). OK, wow, I just rambled on a great deal about that. Hope it was interesting to someone :) -Jeremy

I'd go for P5. If you don't have the preconceived notions of how materials work in P4, P5's material shaders will just be a learning experience, and P5 is soooo far and away better than P4 in this regard. On top of that, P5 includes real dynamics for hair and cloth, when you want to get into that. Your machine is fast enough that P5 should run fine (I run it on a 1.7GHz Pentium 4), but I would recommend at least 512MB of RAM (more if you can). Additionally, though the new renderer won't win any speed competitions (except maybe going up against Bryce :) it is a pretty decent render engine. Many people have said that they don't see an improvement over P4's render engine. That may be true when rendering things that are just using straight bitmap textures (such as many products designed to also work with P4), but the new render engine really shines when combined with procedural shaders from the material room. I think perhaps because procedural shaders are new to the Poser world, even a year and a half after the P5 release, many people are only now starting to make much use of them. Anyways, I'd definitely recommend P5 over P4 if you are at all serious about 3D in general. For example, even if there is a bit of a learning curve to the material room at first, P5 has one of the friendliest shader network editors, and concepts learned here will transfer into other 3D apps. My $0.02 :) -Jeremy