I read that the interpreter has a thing for tabs. Luckily, I prefer tabs over spaces for indentation as well. :) One of those strange errors was from the "Poser 4 Pro Pack f/x & Design" book in the bulgeActor script that was presented. It was entered exactly as it appeared in the book and was checked against the text on the CD, but it kept returning with an error about a null object (geom) in this case. Found the Poser script that does the same thing, but without a separate method, and saw that the validity check on geom had been removed in the book script, so included this from that script: if(not geom): continue verts = geom.Vertices() ... but it returned with 'continue not properly in loop' (?). Well, this was driving me batty since, on the face of it, I could see nothing wrong with it, so I just reversed the logic to remove the 'continue': if(geom): verts = geom.Vertices() .... That worked. Keeps that extra stack reference to get out of the if(), but it does the job. This is one of those idiosyncracies, especially with interpreted languages. They tend to be less tolerant in stepwise execution. Once the 'design philosophy' for Python is understood, it shouldn't be much of an issue. Kuroyume

That must be the "Company Clown." Did you check out the second one from the front: slumpy. "Wah, I hate marchin'..." And the third back, middle is sleeping. ;) Kuroyume

While agree that it looks easy to learn, there are a few idiosyncracies that I want to get used to (such as Dictionaries and Python's particular flavor of exception handling, for example). And, yes, there's hardly anything missing from it! Python looks a lot like Java in its implementation (classes, objects, methods, API imports, GUI support, threads, and so on). When I start getting strange errors from the interpreter, though, it will be good to know why they are occurring and how to correct them without an overabundance of wasted time. Java is also pretty easy, but to get to the real heart of the APIs, especially for application programming, you need the API references (as will be a good thing for Python). But you also need to know how to correctly use them. Thus, in the case of Java, I have about 12 books (3 reference, 3 general, 1 AWT, 1 Swing, 2 2D Graphics, 1 Java3D, and 1 Java Advanced Imaging) to achieve this. Without these, the support application that I'm currently writing for Poser 4 would be on the scrap heap. Nevertheless, it'll be fun to learn and I'm not expecting too much difficulty in that. Already enjoyed the "bulgeActor" script. I'm just one of those people who has to know everything in order to do whatever I want. Damned selfish of me, huh? :) BTW, Bushi, thanks for the book list. I have them saved for later reference. Kuroyume

Forgot to ask: Can you recommend a good book on Python. I always like to have something like this to get the hang of a new language quickly. Thanks again, Kuroyume

Thank you bushi! I'll have to go to the Python site and check out the manuals and tutorials there and go through the examples in Poser4. Arghh! More GUI stuff to learn. Java Swing is bad enough. :) Now the trick will be to not mix up the two when programming... Kuroyume

It's worse than that, ragmaniac. Just watched "The Screen Savers" and they have alerted of a problem with HTML in Explorer 6 and Outlook that would allow malicious code to run JUST BY OPENING A WEB PAGE OR HTML E-MAIL. Boy, I bet I could walk right into MicroSoft with a M-1 Abrams assault tank and the entire Chinese army and they wouldn't notice. MS's internet security SUCKS!!! More holes than the space between atoms in a loosely binded gas. I get one or two Klez.h virus attachments every few days that are caught by Norton AV. People are idiots (sorry to those who aren't ;). Every computer sold should have a big sticker on the monitor that can't be removed that says: NEVER OPEN ATTACHMENTS - ALWAYS SCAN FOR VIRUSES - TRUST NO ONE. The only thing I hate more than spam are viruses. Kuroyume

Doh! Could Poser4 prefs actually be in Runtime/Prefs? Hmmmm.... That answers that... Kuroyume

Well, where else can you find THAT kind of expert information, huh? :P Kuroyume

ronstuff, I do understand the difference; I'm proficient enough at mathematics, especially when related to geometry and 2D/3D space (I did write the 3D engine being used in my application). Let me tell you where the UV comes from (you might already know this, so excuse my hubris). In Cartesian space, points in that space are denoted by three real values, coordinates, artificially mapped mutually perpendicular to one another (but not always). These are located along these mutually perpendicular axes, denoted X,Y,Z, of the Cartesian space, a point located with the triple (x,y,z). In Vector space, there are no 'points'. There are vectors. These vectors need not be mapped mutually perpendicular to one another. The cardinal direction vectors for the Vector space are denoted U,V,W (where have we seen those before?) and by default are normalized to meet at a cartesian coordinate origin (0,0) and have magnitude of 1.0. A place in Vector space is given a vector originating from the intersection of the defining vector's origin which involves a magnitude and direction. In order to place a vector in Vector space not directly attached to the origin requires a displacement vector from the origin to reference it (like an offset). With that said, I realize that the use of the UVW vectors for texture mapping is different than XYZ coordinates, but the theory and implementation remains the same. Whether you are defining XY/XZ/YZ points or UV vectors, they both describe the same thing - a plane. Not a coordinate system, but a geometric construct which could have any number of coordinate systems mapped onto it. This is analytic geometry 101. The W is not even necessary for this discussion any further since its relevance has been discounted. So, although the UV 'textures' described on the plane can be sorted out to reference different texture maps by utilizing extra information (stored in the facet references), they still all lie on the same plane. There is absolutely no way, without an artifice like Poser and human interaction, to distinguish which UV vertices represent one texture reference or another when overlapped; there is no distinguishing information otherwise. Like I said, when you consciously select a particular texture map image for V2's head, for instance, you have made the choice between which overlapped set becomes relevant. In essence, you say "head vt's, meet head texture map (or any other map)." In my situation, the overlapping head vt's and body vt's are in the same box, all jumbled together and indistinguishable (without some hefty work - and still flawed as Ajax pointed out). I cannot select which set references which image since my app is not referencing an image from a particular set of vt's, but creating an image for all of the vt's (or all of those of interest to the user, at least). The alternative that would work would be to create a separate image for each occurrence of 'usemtl' or 'g' in the .obj file, but that would be costly and wasteful. Load the standard Vicky2 into UVMapper. My application creates texture maps from what you see. How do I create two required images from that (which is how Daz has set this up)? What distinguishing features tell me which set of facets must be sorted out to one map and not another? In Poser, you do this consciously by selecting an image to map onto the desired material region. ************ The use of the W is known to me, but I made this inquiry thinking that maybe Daz was using it nonstandardly to distinguish the different texture spaces used by simple differentiation of the values, which would have greatly simplified the situation. Now I am left with probably one viable alternative that is less fallible, less costly, and removes the need for not-so-extensible programming practice (hardcoding something which could change at any time), but requires the user to have some foreknowledge and do some extra work. That is to notify the user that if this kind of situation exists (overlapping texture spaces), they must select the 'regions' that make up a single texture space to create the texture map image for each overlapping texture space. In other words, Vicky2 would require the user to select the head and create a texture map image, then select the body and create another texture map image so that they do not end up in the same image (and overlapped). I hope that I haven't been to brash, here. It's just that the minefield was planted when I incorrectly expected the W coordinate to be my savior by possibly having a significance that it normally doesn't have. Instead, I should have inquired about the basics of multiple texture map images for a single .obj file and avoided the consequences. ;) At the least, this has spotted a potential brick wall early on in development of the application and allows some time to consider viable alternatives. Once again, thank you all for your exquisite inputs. Now, back to work! Kuroyume P.S.: I had the misfortune to be watching the news yesterday morning when the weatherperson starts discussing sunburn alerts. The sweeping title: "UV Skin-dex". Now, if that doesn't make you wonder...

Sorry that I started a war :), but I took the liberty of loading Vicky baby into UVMapper and NOW it makes sense to me. This makes it even more tricky, since the UV's for the head and body overlap in UV space without delineation, it will be extremely difficult to know to create separate images. Instead, my app, as it would basically work, would create a mish-mosh map (that's a new type of texture map) with the face and body overlapping in a single image. Not a good thing. So, the trick works going onto the 3D object, ala Poser, but it wreaks havoc going the other way (obviously no problem when just using the texture template image). Ajax, your tentative solution of checking material groups for overlap crossed my mind, but I agree that it is not a bullet-proof solution. The other possible solutions will be checked out. Never saw regions in .obj files. There are lots of fields not used by Poser and I haven't seen any of them in any of the third-party objects (curves, patches, surfaces, etc). Those that are there are v, vt, vn, f, g, s, usemtl. None of these will get me that crucial information. This may need some indepth discussion with Daz to find a simple resolution. Thanks all of you for being patient and trying to explain how Daz's divided texture maps actually work. Sorry that it took so long to think about loading the geometry into UVMapper and see it for myself. Where's Poser5 to the rescue? ;) Kuroyume

Alright, from what Nance and darkphoenix are saying, the W in these files is inconsequential (for all we know, anyway) and the UV's for the head and body still fill out an entire UV space, but that space is 'tiled' or partitioned into separate files for ease of use (by Poser in this instance). Is that the idea? If it is, then I still have to ask how my app can go about determining the partition. The application loads an image (ideally, a photo of a person) and a figure geometry (.obj file). After the user matches the two, it will produce a texture map of the covered parts of the image to fit the texture vertices. IOW, the image will be pseudo-unwrapped onto the UV plane. For simplicity, I could have the user split the texture map image into its respective images for Poser, but I'd rather that it produce the texture maps in as many files and correct partitions as Poser would expect for the geometry used. I guess the crux of this confusion is how Poser knows that a Daz body texture map only maps to the body and not to the entire figure incorrectly (since, by default, a texture map image covers the UV space, in at least one dimension). It couldn't possibly know the offset in UV space to begin the offset map-section without it being mentioned someplace. As you said, Nance, the obj file knowns nothing about the UV space partitioning. As a matter of fact, the fact that the skin is divided in the materials as Skin Head and Skin Body reveals this. Pulling this and what Ajax has just said, it appears that the missing link resides within the material assignments. The question may be, "Where are they?" I believe this information would reside in the CR2 file; but they are huge files. Even Word on a dual 733MHz CPU and 768MB RAM is sucking wind with these files. Methinks it's going to require some deep study of the CR2 layout for precision in finding them. :( Kuroyume - a needle in a haystack ne'er looked as good a proposition.

Okay, but let's say that someone loads the entire M2 geometry (which has only one set of vt's but is treated as two separate texture 'spaces' as it were) into my app and wants to create textures from a full-person photo. How do I determine A) that more than one texture map is needed to be output (as compared to a standard P4 figure or whatever other fiendish geometries are loaded) and B) which vt's represent which texture map of a plurality. Now, if both the head and body are mapped into a single space, but separated into two files, then there would need to be an ~offset~ to correct for this since each file usually represents a 0.0->1.0 U and 0.0->1.0 V plane. Correct? So, my texture output file may end up being a single image containing the head and body (as if you took the separate head/body texture images and adjoined them into a new image file)? UV coordinates and texture space make sense to me, but you're going to have to explain to me how this is applied over multiple texture files with a single texture space defined. If you think that you can show this graphically, that might help greatly. Kuroyume

WOW!!!! Just seeing this makes me happy that I have Poser4 w/Pro Pack. I might just be able to afford Poser5 now. :) Do you think it'll run on a 1.2GHz system with 512MB RAM and a GeForce4? Kupa, Amazingly Awesome stuff!! I'm going to view those animations a few hundred more times just to make sure this isn't a dream. Keep us posted on progess and please, pretty please, make a version for Mac OSX available soon after! Kuroyume

I didn't even need to get to the results to be unsatisfied. Not worth $50, maybe $10. I hate to diss the guy who wrote it - it was probably his first real application program - but it takes an extremely simplistic approach to a complicated problem, has major bugs, and requires an export to 3ds file format (I don't understand why at all since .obj is very simple to handle). Currently working on something similar in Java to be a little more flexible and user-friendly than Still-to-Real(it'll be slower than a native executable, but cross-platform. And development time and 3rd party library dependence are cut to nearly nothing). This app loads images (JPG, GIF, PNG, BMP, and TIF) and Wavefront .obj files (just like the ones used by Poser) and will allow rotation, scale, translation (basics for 3D), multiple cameras, vertex/facet/group manipulation, undo/redo/restore operations, and, if I'm lucky enough to figure it out before beta testing, some sort of morphing and what I like to call "group-image alignment" (haven't quite fleshed out a method to implement it yet, but the concept is that you select, for instance, an eye facet-group on the mesh, then the appropriate points on the image eye, and the mesh eye will be fitted to it - complex stuff to say the least). Why am I so determined? Because I want a friendly, powerful app to do this type of processing myself. ;) Kuroyume

Just avoid the crocs, mate :) Kuroyume