RELEASED The "Scatter Tool" plugin for Poser

[an0malaus]

The Construct prop in the library is not exactly the same as in the Poser 11 factory default scene, where it's called "GROUND", though they do share the same geometry file, hence my suggestion to check the GeomFileName()

>>> gnd = poser.Scene().Actor('GROUND')
>>> gnd.GeomFileName()
u'/Users/Shared/Poser 11 Content/Runtime/Geometries/Primitives/Construct.obz'
>>>

 

[Ken1171]

But you shouldn't have to worry about that. Just use ParameterByCode() whenever you're dealing with transform parameters.

Very good idea! Why haven't I thought of that? I have used these codes before. This way, at least for transform parameters, I won't have to worry about what they decided to name them.

The Construct prop in the library is not exactly the same as in the Poser 11 factory default scene, where it's called "GROUND", though they do share the same geometry file, hence my suggestion to check the GeomFileName()

I have just checked the vertex count to know which GROUND I am dealing with, because the only one I care for is the plane, not the construct. I don't think anyone would want to scatter over the construct anyway.

 

[Karina]

IMO the *contruct* was just another of SM's really bad ideas:
(as well as replacing the classic texture preview sphere with that scary skull, which is, IMO, "below-standard"...)

We already have many alternatives like BB's "Environment Sphere" which is simply irreplaceable for outdoor renders.
Snarly also offered some great alternatives!
So * Why the dickens* did SM decide that they had to introduce another prop to confuse users??

*My suggestion:*
Discard "the Construct" and that awful skull in the SF preview ASAP!

Both don't have a real benefit.
On the contrary: They add much to confusion (see many previous posts!)

Having tweaked Poser to use neither of them, I never missed them.

K

 

[Ken1171]

Ok, I have replaced the name-based transform parameters with CODE-based ones as suggested, and now I no longer have to keep track of all the naming inconsistencies between different GROUND objects and Poser primitives. I no longer have to check which GROUND is being used, because it doesn't matter anymore, so the code got smaller and cleaner.

I have tested with the Poser GROUND plane, and the Construct GROUND, and it works with either one with the same code now. Very good suggestion from @an0malaus! ^_____^

 

[Ken1171]

Good news - beta-testing has returned no errors. However, I rewrote part of the code to remove parameter names, and replace them with Poser ID codes. As mentioned above, this has reduced the code size and removed all the naming inconsistency checks. I have also moved all the getting and setting transforms to its own class, so if I ever have to deal with this again, I can reuse this class instead of reinventing the wheel later on. With all these changes, I have sent the package for another round of beta-testing again. In my own testing, everything was working properly, but who knows? I don't trust myself to test my own stuff. Just a little longer now.

 

[an0malaus]

With regard to the box-tracking request, and it's inaccessibility from Python, there's another issue. Even rendering in Preview mode won't do box tracking on figures which have Unimesh skinning. They persist in rendering to their actual mesh shape and texturing, rather than bounding boxes, despite appearing that way in preview. Something to be reported as an issue.

The V4, bodysuit and luger figures are all unimesh to support subdivision and don't preview render as boxes, despite appearing as boxes in Preview.

 

[an0malaus]

Python access to the tracking modes is possible as follows:

poser.ProcessCommand(1420) # Full Tracking
poser.ProcessCommand(1031) # Fast Tracking
poser.ProcessCommand(1092) # Bounding Boxes Only

 

[Ken1171]

Almost there with internal beta.

Even rendering in Preview mode won't do box tracking on figures which have Unimesh skinning.

I think that's Ok, since people are asking for bounding box display just to speed up previews, not to render or anything.

Python access to the tracking modes is possible as follows:

Oh yeah - I keep forgetting these codes since they are NOT listed on the official PoserPython documentation. But I think that, in this particular case, it is not worth adding them to the tool because these preview modes cannot affect only the scatter objects, which is what the display styles in the tool are aiming for. These tracking modes can only affect the entire scene.

The reason I have included this feature is to allow easing up the GPU load, so we can have better performance when composing the rest of the scene. I also offer the option to make the entire set of scattered objects invisible with 1-click, which is perhaps a better option than any kind of preview mode.

 

[Karina]

Frankly - I never used the bounding boxes after a first try and considered them utterly useless, unless you're still on a Commodore C-64: File:Commodore-64-Computer-FL.jpg - Wikipedia

Switching to Hidden Line (CTRL-4) plus also making any other figures/props not currently needed *invisible* was a much better choice.
I think you can skip that glitch without any problems for 95% of users / ... unless they still use a C-64 of course

K

 

[Ken1171]

Switching to Hidden Line (CTRL-4) plus also making any other figures/props not currently needed *invisible* was a much better choice.

Indeed, and since the tool covers both of these options, I think that should do the job.

 

[Ken1171]

For today's update, I have optimized the "Align To Surface" module, so now it runs visibly faster. That was the slowest part from the whole, and we are no longer penalized for using it. ^___^

 

[Ken1171]

On a side note, I was considering including an option to run the tool from a CR2 at the "Character" library. However, something has changed in Poser 11 that prevents me from doing that. When executed from the CR2 in the library, PoserPython becomes unable to find any of the included compiled modules (PYC files). The error messages claim to be looking for the uncompiled PY versions, so it finds nothing.

I am pretty sure this wasn't happening before, so it must be something that changed in the recent Poser updates from Rendo.

 

[Miss B]

*My suggestion:*
Discard "the Construct" and that awful skull in the SF preview ASAP!

Both don't have a real benefit.
On the contrary: They add much to confusion (see many previous posts!)

Having tweaked Poser to use neither of them, I never missed them.

You and me both sir!! I couldn't agree with you more. I was so happy when I discovered Joe/Netherworks goodie to get rid of that ugly head in the Material Room, and then thrilled to discover the Poser 10 Workspace in the Poser Environments in the Scene library. Made My Day!!

 

[caisson]

Digression, but the Construct was added because Superfly HAS to have a complete environment because everything is reflective in Superfly. It also allows building a 3d environment instead of merely simulating one with a photo, plus the UV's make adding skies from equirectangular panoramas a snap (4:1 - chop a 2:1 eq. pano in half, apply to Background. Tile suitable ground texture. Add infinite light. Done). Could it be better? Expect so - automatic physical sun/sky like Octane (and others) would be awesome. At least the original Ground is still there and can be swapped out for those who choose.

@Ken1171 - looking forward to this. I want to see how many copies of my quarter million polygon tree it takes to trash Poser. I can render 7 easy, I just got bored placing them

 

[Ken1171]

@Ken1171 - looking forward to this. I want to see how many copies of my quarter million polygon tree it takes to trash Poser. I can render 7 easy, I just got bored placing them

You can always render billboards and put a whole forest in there - with 1-click.

 

[Miss B]

Digression, but the Construct was added because Superfly HAS to have a complete environment because everything is reflective in Superfly. It also allows building a 3d environment instead of merely simulating one with a photo, plus the UV's make adding skies from equirectangular panoramas a snap (4:1 - chop a 2:1 eq. pano in half, apply to Background. Tile suitable ground texture. Add infinite light. Done). Could it be better? Expect so - automatic physical sun/sky like Octane (and others) would be awesome. At least the original Ground is still there and can be swapped out for those who choose.

OK, thanks for the remind, because I forgot about Superfly's need for a total environment. It's the main reason I ALWAYS use BB's EnvSphere, and Snarly's EZDome, which utilizes BB's EnvSphere, even if I'm not planning on rendering in Superfly. I do use Superfly more often than not, but in the beginning, I wasn't sure how easily I would take to it. Now I'm fairly comfortable with it, but it took a while.

 

[Ken1171]

Internal beta-testing has sent me their Ok tonight, so it's ready to go. Just need to make some promos and store materials. I also want to make a few video tutorials covering different aspects of using the tool, creating resources, and best practices.

 

[Ken1171]

Here's a walk in the forest with grass, plants and billboard trees, rendered in Poser with Superfly. Created with 4 clicks on the Scatter Tool.

LINK HERE

 

[DanaTA]

No image!

 

[Ken1171]

No image!

I know, DA didn't let me share the image, so I had to replace it with a link.