RELEASED The "Scatter Tool" plugin for Poser

[Ken1171]

I am so glad you are going to release this here at Hivewire. I can hardly wait to get it and start using it! Thank you so much for creating this.

Thank you for the feedback! I am having a blast playing with this, with all the different applications. ^___^

 

[KageRyu]

This is fantastic so far.
I thought of one more idea - not sure if it's doable - but scattering objects randomly in 3d space from a reference point with no actual ground object. Say for aerial objects, like flocks of birds, cherry blossoms, dandelion seeds, asteroids, or space invaders.
I say from a reference point/object so that there is some way to control altitude or grouping/cluster positioning.

 

[Karina]

Now on solids with surface alignment. Everything seems to be working.

View attachment 59261​

Reminds me of "Le petit prince" by de Saint-Exupéry:
The Little Prince - Wikipedia

Excellent work, mui obrigado!

K

 

[Ken1171]

scattering objects randomly in 3d space from a reference point with no actual ground object.

The reason I use a plane or solid is to use the vertices to track where the objects will end up, so I can control overlapping. If we do this entirely at random, chances are that many objects will end up inside others, since there is no reference locations to track.

Excellent work

Thank you! That was like a little planet indeed. It's a small world. ^^

 

[Ken1171]

I am having some technical difficulties during this beta-testing. It looks like running the tool in the same Poser 11 installed in different computers yields different results, so I am still scratching my head. SMS told me Poser has its own self-contained Python installation, and we cannot change it in any ways, like installing libraries and things like that. We just cannot change or expand it. At least in theory, this on its own should be a guarantee that if my code works in my Poser 11, it should work in any other Poser 11, no matter where it is installed.

However, reality is showing me something else. Even the WX interface had different results in different computers, which should not be possible - but it is happening nonetheless. The code to handle the WX default font works in my computer, but crashes the tool in another - both using the same Poser 11 version. How is this even possible? A mystery? Should I call Fox Mulder?

The code to handle Poser's default GROUND works in my computer, but crashes in another one. The default ground cannot be deleted or even renamed, so it should be the same, but the error code tells me it's a different one. How come? Is this a case of alien abduction that genetically modified the default ground plane in some mysterious way? Is this an X-File?

Still investigating.

 

[DanaTA]

Ooooh. I hate this type of problem! When code works OK on one computer, but not on another one, it is very annoying! It's as bad as intermittent errors.

Are all things the same on the different computers? Sometimes a different driver or something like that, different installed software or libraries (not 3D libraries) will make a difference.

Dana

 

[KageRyu]

The one variable I could think of is maybe 32 vs 64 bit installs of P11... but I thought P11 was 64 bit only.
As to SMS statements, all evidence and firsthand experience with SMS has proven to me that their claims and statements are unreliable and untrustworthy in all regards. - especially where Poser was concerned (after all...weren't we all guaranteed a way to keep Game Dev running if SMS sold off poser?).

I do hope you are able to get it sorted, I would hate to see this tool get back-burnered.

 

[Ken1171]

Are all things the same on the different computers? Sometimes a different driver or something like that, different installed software or libraries (not 3D libraries) will make a difference.
Dana

I think this is way more specific to Poser itself. Like the default ground plane having different properties in different installations of Poser 11 in the exact same version? Or the WX interface code work in one Poser 11 installation, but not in another? The WX GUI depends exclusively on the Python version Poser has, which cannot be modified by anyone. If the Poser Python version must be the same, how come WX works in one Poser 11, but not in another? How is this even possible?

I am investigating this with the beta testers, but it's slow because each is at a different time zone. I think I have already solved the WX code issue, and I have pretty much narrowed down the issue with the default GROUND plane. I know exactly what line in the code causes the crash, though it doesn't happen in my computer. I can't figure it out until I can reproduce it.

In my Poser 11, the GROUND plane has a property called "Turn", but in another computer, this property is claimed not to exist. The GROUND plane cannot be deleted, or even renamed, so I wonder how it seems to be different in different P11 installations. I am running some tests with the beta testers to narrow down the possible causes.

I would hate to see this tool get back-burnered.

Not a chance! ^____^

 

[Ghostman]

There is a new official update for poser that was released yesterday. No news about it though but severeal people had issues with python in the earlier Build version. From what i understand they've changed the Python Lib.

 

[an0malaus]

It's somewhat unfortunate that the choice was made to name the Construct environment prop "GROUND", since it has different geometry. If a user changes their default scene preferences, they could easily have an old ground plane instead of the contruct. The geometry of the GROUND prop should be inspected (at least the filename) to confirm which it is, before making any assumptions.

 

[an0malaus]

It's not entirely correct that Poser's bundled Python cannot be changed in any way. It is completely possible to link in additional or replacement packages from an OS installation of Python 2.7 in order to overcome issues with the packages that are bundled, or use other ones that are not supplied by default.

On macOS Poser, for instance, the PIL (Python Image Library) is broken to the point where JPEG files cannot be saved. I have a version of Pillow (a more capable replacement for PIL) linked into Poser Python to fix this.

If you have a need for additional beta testers, I would be glad to contribute, since sorting out Python scripting issues is how I spend most of my time.

 

[Ken1171]

There is a new official update for poser that was released yesterday.

I have it installed already.

It's somewhat unfortunate that the choice was made to name the Construct environment prop "GROUND", since it has different geometry. If a user changes their default scene preferences, they could easily have an old ground plane instead of the contruct. The geometry of the GROUND prop should be inspected (at least the filename) to confirm which it is, before making any assumptions.

That's what I first suspected, and that would make sense of the error message I am getting. However, under closer inspection, the Construct internal and external names are both "Construct", so maybe they have changed this? I have loaded this prop from the "primitives" library. Or perhaps there is another "Construct" somewhere else? If that's the case, where do I find it?

It's not entirely correct that Poser's bundled Python cannot be changed in any way.

Thanks for the info. I took what SMS told me as correct since I don't know any better. But if I could add libraries to Poser Python, wouldn't they only exist in my own installation? If that is so, then I couldn't use these libraries to create tools to be used by other people because they wouldn't have the dependencies, I assume?

Oh yes, and WELCOME to the HW forums! ^____^

 

[Ken1171]

It's somewhat unfortunate that the choice was made to name the Construct environment prop "GROUND", since it has different geometry.

I have launched Poser to "Factory Default", and the Construct actually replaces the default GROUND. That's why loading the prop from the props library doesn't have the same name. These are 2 different things. Now I could see what was causing the crash. I didn't know this other construct had the same name as the default ground.

I have added an extra check to see if the vertex count matches the default ground, and if not, then I use the construct's parameters instead. This was not the only rule exception I had to check for, since SMS didn't seem to care for following their own convention standards for naming parameters. Some of the Poser primitives rotate with "yRotation", while the standard name convention for rotations was supposed to be "yrot". The ground plane is also an exception, where Y rotation was named "Turn" as both the internal and external names. The Construct uses "yRotation", which breaks the convention again.

These inconsistencies make things difficult because I have to check for all the exceptions in code, making things more complex than they were supposed to be. If only they would follow their own naming conventions...

I have tested the tool in these 2 cases (ground and construct), and it now understands how to handle the object naming confusion. Back to beta-testing again, but at least now I have prevented the confusion between the 2 kinds of ground. I think this might have resolved everything. Fingers crossed!

 

[Miss B]

I have launched Poser to "Factory Default", and the Construct actually replaces the default GROUND. That's why loading the prop from the props library doesn't have the same name. These are 2 different things. Now I could see what was causing the crash. I didn't know this other construct had the same name as the default ground.

There's something else available that you may, or may not, be aware of. If you go into Runtime > Libraries > Scene > Poser 11 Environments, there are 3 options: Alternate Construct, Developer's Workspace, and my favorite, Poser 10 Workspace. I happen to HATE the Construct in any way, shape, or form. When I want a "ground" plane, that's ALL I want, so using the Poser 10 Workspace allowed me to go back to what I was used to for so many years before Poser 11.

That said Ken, I have no idea how many other folks have done this with their setups, and may very well be another reason why your script isn't working on other computers as it does yours. Just something to think about.

 

[Ken1171]

That said Ken, I have no idea how many other folks have done this with their setups, and may very well be another reason why your script isn't working on other computers as it does yours. Just something to think about.

Good point. I will include in the documentation that the tool is "compatible" with either the default ground plane or the default construct when it comes to whatever Poser considers it's "GROUND". I don't even think it would be a good idea to scatter over any kind of construct, since in most cases people wouldn't want to scatter all over the walls or ceiling.

 

[Miss B]

Very true, but I "think" Poser 11's "default ground" IS the Construct, or at least that's how I perceived it when I first started playing with P11.

Of course, since Bondware took over Poser and its development, and the old dev team is back, or most of them, things may have changed. I just assumed back when P11 first came on the scene, they kept the name default Ground because that's what folks were used to. The Construct is, at least to me, nothing like a "ground" plane.

 

[caisson]

Re. scattering figures - I'd like to return to my feature request for an option to 'Use Proxy' i.e. bounding box. While the Preview may stumble with many vertices, which is to be expected, the joy of an offline renderer with oodles of RAM is being able to feed it lots of geometry

Yes, I want to see if I can crash Poser!

 

[KageRyu]

Re. scattering figures - I'd like to return to my feature request for an option to 'Use Proxy' i.e. bounding box. While the Preview may stumble with many vertices, which is to be expected, the joy of an offline renderer with oodles of RAM is being able to feed it lots of geometry

Yes, I want to see if I can crash Poser!

I actually would like to make this feature request direct to Bondware (I had suggested it to SMS numerous times). Having a bounding box preview mode is invaluable in any 3D software. When I had better finances, whenever I would get a new workstation goal number 1 was to push Lightwave to the machines limits to see what it took.

 

[Ken1171]

Very true, but I "think" Poser 11's "default ground" IS the Construct, or at least that's how I perceived it when I first started playing with P11.

It seems like the construct has replaced the Poser 11 ground plane by default, and I have reverted that back to the old ground plane in my preferred state. That's why I made the GROUND the default scattering plane - I forgot most people will have the construct instead. But that setting is just so the program has a default plane - people don't have to use that if they don't want to. They would soon realize that would be rather pointless.

I'd like to return to my feature request for an option to 'Use Proxy' i.e. bounding box.

The thing is - Poser supports bounding box preview mode, but the feature doesn't seem to be accessible from Python. You can switch your scene preview mode to bounding box by using the little pull-down glyphs below the viewport, as seen below. I have marked it in yellow. We cannot choose what to affect - this will affect everything in your scene. You just have to remember to switch back before rendering, for this might mess it up. In the example below, this is Dawn in bounding box preview mode.

​

 

[an0malaus]

The safest (name invariant) way to access transform parameters in Python is to use ParameterByCode() and the poser.kParmCodeXTRAN, etc. constants. They will work no matter what the creator has called the transform parameter, whether it be xrot or Bend or xRotate. This only fails in the VERY rare case where an actor has multiple transform parameters with the same code (they have to have different names, though). I have used that technique when I wanted the option to have conforming limbs NOT follow the base figure (like a very loose shirt collar not bending with the neck).

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