Is there a Python script available that can scale all objects (including lights) in a scene? The reason i'd want something like this has to do with the problems with firefly that Ronstuff uncovered sometime back. Thoise problems can be overcome by scaling up all objects by a certain amount (around 200%) Obviously a Python script that would let you scale all things by an amount you determine would be infinately helpful for a number of applications. Even moreso if you could check and uncheck objects (amazing shrinking vickie?) Ockham... Ya know I'm lookin at you? :D

Easy enough, but what do you mean by scaling lights? Changing their distance from origin, or changing intensity? And what if the intensity is already 100%?

Also, should cameras change their Dolly Z as well?

Attached Link: http://www.renderosity.com/messages.ez?Form.ShowMessage=2052752&Form.sess_id=25929689&Form.sess_key

Berserga, I have just spent two days thrashing thru Poser5 because I did not find Ronstuff's uncovering, which is posted on that other forum with doublehelix in the name. Poser5+Firefly is indeed in trouble because of math/decimal places.

This script is needed.

I just finished taking a scene with one light, one character with texture and scaling it as follows: seclect body on character, hit the scale dial. I kicked it from 100 to 1000. The only other thing I scaled up was the ground plane.

Result:
DRAMATICALLY BETTER RENDER TIME
RELIEF FROM ARTIFACTS due to shadows in animation

I did NOT find that my light needed to be scaled in any way, either by distance, intensity, etc. That is only my experience after one experiment.

I DID have to reanimate because of camera keyframes, was in a hurry so did not try to "scale" the camera/animation, if that even makes sense as a concept.

This is a topic whose time has come back around.

::::: Opera :::::

By scaling lights I just meant spot lights... I believe they do have a scale Paramater if I'm not mistaken. about the camera issue, I just don't know. I havn't put this stuff to the test yet, but I definately trust Ronstuff's opinion on stuff like this (and the evidence he posted). If decreased render time is a benefit as well then... my, that is very exciting isn't it? :)

It seems that you'd need to pull the cameras out to get the same picture when everything is scaled up...?

yes, but it may not be trivial...not just a proportioned pull back. Affects depth of field, focal length, angle, etc. ::: Opera :::

Ronstuff's link on this is at RDNA forums. I'm interested in this as I'm startimg to play with water effects again. The lights are another issue as far as scaling up to 1000%. As you mentioned, there is a Z axis problem on spots/shadowcams and cameras. We parented everything to an invisible primitive and used that to scale the scene. I've been manually redoing the spots and now just save a monster lightset to the library. This would be very useful.

DRAMATICALLY BETTER RENDER TIME

Hmmm. Would scaling up improve Firefly render time for all scenes?

If so, whoever writes this script is going to get rich. :-)

Attached Link: RDNA Poser 5 Exploration Forum

Yes. Scaling up improves rendering time for all scenes. However, the most dramatic difference is seen when those scenes use the advanced features of firefly, such as displacment, raytracing, procedural materials, refection, etc. The reason is simple. Firefly is not *optimized* for small scale work. Poser scale is very, very small. So when one goes into small areas of small things, the numbers being passed to the rendering engine are incredibly small. They do not need to be, however. Poser's scale -- for us, in general -- is entirely perceptual. We percieve it to be small because the figures we use in it are small. The figures have never been scaled up from the orginal release. All figures currently created for poser are built around that original scale. Poser's world scale is roughly around a million poser units. That's a LOT of space to play around in. Nor does the scaling always need to be a factor of ten. Half that often works well. Sometimes a greater factor will apply. But scaling, overall, absolutely does have an impact on render time. It also impacts performance, level of detail (it does increase when using displacement), and more. This is the sort of cool stuff one gets when one vists the RuntimeDNA Poser 5 exploration forum. Plus you get good advice on *using* poser 5 in every day things, and you can lern about hair and cloth and even show off experiments and more -- all in a very cooperative, friendly, helpful environments. ALthough you do get much, much longer posts over there. So you do have to read a bit more. Oh, and, lest any one wonder *why* I'm so big on that forum, or suspect me of wrongdoing, well... I *am* one of the moderators for it. ;)

Parties don't start for a while..; ) so, I just scaled up a scene from scratch and the spotlights I think, will have to be moved on all axis(makes it a challenge). It's amazing how much gets fixed when you get up over 400%...

The scaling factors for lights and cameras do not operate in the same method as the scaling for physical objects -- and are NOT saved in the pz3 or lt2 file. Those have to be manually hacked. Also, a scaled scene often requires a different lighting and camera set up. Since many of the sets I make require me to operate with camera bounds of 300 or more on the dollies, I've learned this the hard way! So scaling the lights and cameras isnt what needs to be done so much as moving them out in a spherical pattern formt he origin point -- which would not work for items located at the origin point. (say, for example, you had a nice little 5 point lightset around the scene, but a candle with a dual 180 spot set on it within the scene. moving them all out while the scene is scaled up would pretty much wreck the lighting of the candle) So, in my opinion, a controllable scaling script for only the objects in a scene -- ideally without resorting to parenting everything so that you could maintain individual item zero points -- would be awesome. Otherwise it would just be a matter of parenting everything to a single item and then scaling it all up at once, which is what is done already. Script like that would be useful.

i scalled up a full ten times because I was dealing with a big heap of what ynsaen is referring to...close up of complex model with heavy texture, bump map and procedural materials and intense Firefly settings. I was getting artifacts. When I scaled up, the artifacts went away (with the addition of a slightly larger shadow map) but I then discovered the benefit of the faster render time. It's simple...the more fine detail you have, the deeper into decimal-place calculations you go and the unhappier Firefly gets. It bogs down and in the end actually does not calculate properly, that's why you get artifacts. A script to scale everything up in a currently existing OPScale (orginal poser scale)? That seems like a valuable script, even more so if the camera/keyframing can be adjusted (I am not optomistic about that). But.... What about the concept of permanently working as OPSx4 or OPSx10 as standard operating procedure? I will be testing this out because I am building many new scenes for a big animation, and believe me, I will be rendering at OPSxsomething. So far the biggest 'getting used to' is that pushing the camera around takes 10 times more mouse dragging....wait....can you scale up a camera? More later.... ::::: Opera :::::

no, camera scaling operates differently, sadly. To some extent, yes. But not entirely effective. however, there is this cool thing you can do -- click on the settigns in the param palette and type in a number. After doing this a Lot, you sorta get a feel for where you need to be with it. I do work at a larger scale almost always. Have since P3. It was just easier because I worked with a lot of static stuff imported into the scene back when that wasn't poser ready, so to speak. It is handier. Truthfully, I just sorta thought everyone did until recently, lol

ynsaen,
I HAVE been having success in the last two hours working from scratch compeletely scaled up. In addition to scaling up my figure to 1000, I did the same to the light and the camera. Once I got oriented, moving the trackball to position the camera progresses normally. I DO sometimes open the fieldbox for a parameter and type in a value, but more often move the camera with the trackball and hands, etc.

Please see my next post for the bad news.

::::: Opera :::::

Message edited on: 12/24/2004 15:16

To anyone reading this thread.... In my excitement at solving my Poser5/Firefly "artifacts in animations" issue, I reported significantly improved render times. Now, after some sober tests this morning, I am retracting. Under the conditions I am working, the render times are about the same, either at the Original Poser Scale or at 10-times scale, keeping all other factors equal. My misconception came because of changing too many factors at once last night in a rush to both solve my 'artifacts' issues and also discover what contributes to slower renders for my type of scene. So, I apologize for the false alarm. I still will work scaled up from now on, because of the artifact problem. See a new thread I am just starting about render speeds. ::::: Opera :::::

You could parent your figures, cameras and spot lights to a prop box. Scale the box, and and the objects scale along with it (and it seems to save too). I have just tried parenting a V3 figure, conforming clothes (conformed to V3 but parented to the box), one spot light and both the Main and Aux cameras. As I dial up the scale of the box prop, V3 and the light on her seem to remain still as the ground appears to shrinf away (ie. the camera is scaling up along with eveything else). Regards, Sway

Sway can you say if your renders are any faster, keeping all else unchanged except scalling? ::::: Opera :::::

Actually, this is how the mechanics of the process works: Remember that this solution was created to address problems with Raytracing in Firefly, and to the best of my knowledge it is not required if raytracing is off. There is a very good reason why I've recommended the technique of parenting everything in the scene to a prop box rather than just scaling each object. The prop box (and simple ball) have their origins set to the World Origin in Poser. If you scale them up you will notice that they scale from the "floor" up, and keep their place on the ground. Other props (such as the high res ball) and most Poser objects have their origins located at their own center of mass. This means that they will scale from that point outwards, rather than from the common world center. The result is that when you have multiple objects in the scene, scaled on their own origins, they no longer have the same spatial relationship to other objects (they are not in the same place relative to each other). So, it is important to think of this technique as scaling up your 3D WORLD and not just scaling up your objects - and the only way to scale the world is to make everything scale from a common point. That is where the box comes in. By parenting everything to the box, INCLUDING spotlights AND camera, and then scaling the box, you are effectively scaling everything around the world origin. When the PARENT of an object is scaled, all of the child objects scale about the same point as the parent and not about their own centers. So this is about the easiest technique I've found that will produce the desired result in most situations. Of course, you want to turn OFF the visibility of the box so that it does not render.

P.S. It is easier than it sounds - you don't have to parent EVERYTHING - just the few things that are parented to the UNIVERSE. All the things that are conformed to or parented to one of those objects will follow their parent, so they do not need to be re-parented to the box. It would be great if a script could be written that would do that for us. Especially if it allowed us to choose the scale factor. Many scenes do well at 500% but I've found that some require scaling as high as 1000% (10x) to be effective. The only things that do NOT scale with this technique are P5 procedural textures (fBm, brick, cloud, weave, tile etc.) - they will have to be scaled manually, but even without re-scaling sometimes you get decent results, so its best to do a trial render before taking the time to adjust them. As for render times, there WILL be differences. Some things will render faster, and some things will render slower - averaging out to be about the same as the unscaled scene. One thing that will really slow things down is close-ups of high resolution textures.

Well blow me down. Everything scales when parented? I obviously have not tried it. It must be frustrating for you to watch our newbie fumblings unfold...LOL Thanks (again). And 1000% fixes everything fixable(as you said).

Yep - it all scales together - cameras, lights and objects. In fact unless you intentionally leave one object in your scene unparented as a reference point, when you scale up the box, you will see no noticible change in the preview window. But don't be fooled by the fact that it looks like nothing has changed, because the NUMBERS have been changed even though the relative aspects of the scene appear to be the same. BUT there is one little caveat: When you first parent the camera to the box, it will shift position. You must correct that BEFORE you scale the scene up, so after parenting the camera to the box, re-position it, and then scale the scene up - everything stays in its relative place.

So, is Curious Labs aware of this? Seems like it would be a fairly simple fix with a lot of benefit. Either scale up the Poser objects (by a whole number, for easy backwards compatibility), or tweak Firefly so it can handle Poser scale.

Well, I put a good part of two days of my life into chasing artifacts in animation that was due to this problem, I believe I should write them a letter with links to this thread, my thread and Ronstuff's research page. Will do so. ::::: Opera :::::

Ronstuff, did you look at my thread here.

The problem I encountered in animations was NOT raytrace-driven.
I definately had the raytrace box turned off in my render settings.
I don't like raytrace for my close-ups; depth shadows are my friend.

Yet NO solution worked until I scaled up.

Please advise.

:::::: Opera :::::

Message edited on: 12/25/2004 13:41

Moreover, I'd like to say this, just so it is in the mix.

Over a year ago, I did some experimental high-res test animations in Poser4 Pro Pac. Very close up, high frame rate, hi-res textures, subtle, small movements. One frame is VERY NEARLY the same as the next. Nothing was visibly amiss on the individual frames...they looked GREAT!. But placed next to one another in a dense animation, it is obvious that some sort of 'compromise' calculation was taking place in the deep shadows and at high acute angles (for instance on the side of the head)

The result was "flicker".

I personally have no desire to go back to flicker-land and test my hypothosis, but I intuitively believe this problem is intrinsic to Poser, period, with certain types of render. It's that sever decimal computation that either is not carried out to sufficient places, or is rounded up/down in a sloppy fashion.

Now, the addition of the power of Firefly has certainly brought this intrinsic problem to the surface. Ronstuff detected it in 'black spot' artifacts on individual frames in raytrace renders. There are possibly other spheres of working in Poser that are negatively affected by the small-scale universe.

I suggest that, with further experimentation, this idea of working scaled up, or having CL transform the scale altogether, or fix the decimal math algorithms, becomes an important basic strategy awareness for Poser users.

::::: Opera :::::

Message edited on: 12/25/2004 14:15

operaguy: I didn't see your original thread before posting here, but you are correct about other problems which may be resolved by this fix. In fact in my original thread on the subject I did mention that possibility. It is just that the only things I have actually tested and verified are the raytracing aspects. So I should have said above that this technique has not been VERIFIED for anything other than raytracing. It appears that you have discovered another possible use, and if your results are predictable and can be duplicated by others, it would be verified too. I have found that there are also MAJOR improvements in cloth behavior when the world is scaled up. I can finally make cloth that is not either stiff as heavy canvas or flimsy and fluttering like tissue paper. When the world is scaled up, you can get the cloth to drape and sway just like cotton or silk or just about anything. At least that is the way it appears, but I haven't done all the controlled testing necessary to verify it. randym77: Yes CL is well aware of this and I'm working with them on a solution. The problem is complex, however, because there are so many different aspects to Poser. It is made even more difficult by the fact that Poser contains 3rd party modules that have their own unique requirements to interface properly with the other modules. So, it is difficult to apply a fix across the board which does not turn out to introduce problems in unexpected areas. So CL IS working on it, and is doing their best to see that other problems are avoided, but that involves a lot of testing. I'm confident, however that they will resolve the issue in the best possible way - whatever that turns out to be.

For Poser 6, or will it have to wait for Poser 7 or later?

That's very timely for me, that cloth information...I am just about to venture in there. I will go in scaled up, believe me! Thanks Ronstuff. I wish other people WOULD verify the animation flicker problem and that it is solved by scaling up. Just make a simple animation from a figure with intense texture and bump map, go in real close (focal length on camera of 135 or so) and make a short anmation with just the head twisting. 30 FPS. I BET you will get flicker on depth shadow settings that can only be solved by jacking the shadow map WAY up, or by scaling up. I also bet the flicker can be found in Poser4 renderer. ::::: Opera :::::

I can't really disclose any confidential information I may have about Poser, but I CAN tell you that addressing technical issues and improving workflow are numbers 1 and 2 on their priority list ;-) Sorry it took me so long to find this thread, but I just can't get around here as often as I'd like. Most of the really knowledgable P5 folks are hanging out at RDNA, so if you want faster and possibly more accurate responses to your P5 questions, come on over to the P5 forum there.

Sounds like this isn't a Poser 5 issue, it's a Poser issue, period. But if it's fixed in Poser 6, I'll be first in line to buy it...

Regarding animation flicker, I have heard of this happening in other render engines, it's not a Poser-related problem but a render solution issue.

Right - this kind of problem is not limited to Poser. These days with more software developers depending on 3rd party modules and plug-ins, the problem is compounding. It is no longer financially viable for a developer to underwrite the cost of creating their own render engines, shaders, cloth, hair etc. and still keep up with the competition. So we have issues of compatibility between components that need to be addressed by each application. In fact I was just talking with Roman Ormandy (CEO of Caligari - Truespace) at a showing of the new Truespace 7 software, and they are having similar issues that they are addressing. It is really hard to find every different issue until the application is fully integrated and in the marketplace with thousands of people doing different things with it. Anyway, some of you might be interested to know that Truespace 7 will have a material system very similar to Poser 5, and it looks like swapping materials will be relatively easy.

animation flicker is obviously caused when the interpolation from frame to frame is "off" mathematically. The render engine is forced to calculate values for location and hue for a pixel without having sufficient precision. It rounds or truncates according to a crude rule rather than a deep, precise rule. Therefore, shades of color/black and objects 'jump around' instead of transitioning in a perfectly smooth arc from one keyframe to the next. I am relieved to have a solution, and since I am building all my scenes from scratch (no legacy files that will have to be scaled up) the pressure is off. Now I am trying to get Mimic to behave! ::::: Opera :::::

Well, I'm assuming that you are rendering sequential stills frame by frame instead of rendering directly through a codec. If not, then some of the noise could be coming from the compression. Likewise the image format for the stills should be as lossless as possible before combining into an animation. I use PNG format but TIFF would work too. In Poser 5 you can also increase the accuracy of frame-to-frame pixel interpretation by lowering the minimum shading rate (to at least 0.5) and increasing the pixel samples to 4 or 5. Don't be too quick to blame Poser's mathematics - it has a higher degree of mathematical precision than any other 3D program I've seen. The problem is with non-CL modules which were originally developed for other applications which had LESS precision than Poser.

Well, in response, since the flicker problem instantly resolved as soon as I scaled up, without changing other factors, doesn't that indict the too-small-scale of default Poser and the decimal problems associated with it? However, from your last sentence, it seems you are pointing the finger specifically at the Firefly render engine, as opposed to Poser itself. Okay. But was the Poser-4 engine also non-CL and then tacked on? Because I get flicker with that engine also. I am rendering out to individual images in full-sized loseless TIFF format, 1.4MB per image. When assembled into a quicktime clip, I always first observe the uncompressed gigantic film thus created...before exporting out to a .mov compressed clip. To make sure it had nothing to do with any codec or Quicktime issue, I did a test directly out to .avi. Flicker. My minimum shading rate has been consistently set at 0.2, with pixel sample at 3. ::::: Opera :::::