Request for Clear, Public and Reliable Support for Variable Geometries in Poser!!!



  • One week ago I didn't know anything about the Poser API, so I could't say anything about how well it supports addons. Since then I've read every single line in the manual about geometries, events and callbacks multiple times - some parts maybe 20 times over and over. I checked every single script shipped from Poser 5 to Poser 2016, and read everything available in the internet that matches the API's keywords.

    My conclusion is that there is very limited, poorly documented and completely unreliable support for variable geometries. I've read complains back to Poser 5 about this.

    The basic problem is this: every object (= actor) in Poser (say a foot or a hat) has a mesh (a series of vertex X/Y/Z, vertex lists (= sets) and polygons). This is what's known as the geometry. The actor also has a list of morphs (which is just a series of linear deltaX/Y/Z) and magnets (which just modify the X/Y/Z in some no-linear ways). Of course the object can be part of a skeleton rig, but never mind that for now.

    The problem is, Poser only reliably supports static geometries. The vertex X/Y/Z can change, but the number of vertexes and the lists of polygons cannot reliably change. Every time you talk about changing the geometry in Poser, you're asking for crashes. So if you do a Polygon Reduction, expect crashes. If you do a Figure Combine, expect crashes. I've had plenty of those, and have several dozen files that I have noted down through the years as damaged, and what they all have in common is Polygon Reduction and Figure Combinations. My experience cannot be unique!

    The problem gets worse in the API. The API has a way to change the geometry of an actor on the fly - hooray!! That's called SetGeometry(). But it has no documentation of when that can be done, how that can be done, or any recipe for how to do that reliably. The manual is exceedingly poor for that crucial function, there is not a single sample in any Poser version, and once you start to use it - you guessed it, you're asking for a helluva pain of mysterious random crashes.

    That is extremely shoddy work!!! Either provide the function reliably and document its usage and limitations, or accept defeat and remove it from the API. It is a cruel joke to provide such a magnificent feature and stoke hopes in the API programmers just to have it work worse than a 30-years old clunker.

    See, this is what one could do with python scripts if that function worked:

    (a) Script that does boolean operations (join, intersection, subtraction) on solids in realtime. That way one can say create an animated hole in a plane by doing a subtraction between that plane and an invisible pyramid-like prop that is passing through the plane.

    (b) Script that changes a text prop in realtime, based on the contents of a text file. Much better than creating 50 text props for 50 different texts.

    (c) Scrips for fluids, gas, clouds and metaballs in realtime.

    (d) Script that does subdivision per material groups (instead of for the whole figure) on the fly.

    (e) Scripts for animated prop breakup (slice a prop along planes, then animate the parts away).

    (f) Scripts for animated procedural surfaces.

    (g) Script to unbutton or unzip a cloth dynamically - just assign a special material name, the script detects that material name, automatically subdivides the strip with that material in two vertical strips, adds a parameter, and separates the two strips per the value of that parameter.

    (h) Script that smooth welds different props on the fly.

    And so forth. SM doesn't have to write all that. SM only needs to make one API function to work reliably ( SetGeometry() ) and then people with interest will have a way to provide that on their own. But while that function has a mood worse than certain angry politicians, that will only get burned out bona fide API developers who give up on further work.



  • By the way, I can prove my assertions above by my work on metaballs. I've thrown in some 30 hours already on this thing; it only took 4-6 hours to implement the metaballs algorithm (it's really easy) and bake a list of geometries in memory, but now I've been fighting for 20+ hours to get the list of geometries to update in realtime.

    So my effort to implement X has taken 30% of the time to implement X, and 60% of the time to blindly fight hidden idiosyncrasies in the API. I want to program metaballs, not fight the API! The first 30% was heavenly bliss for a programmer to literally see his work pop in his eyes, the other 60% is just hellish unproductive and stupid frustration. My experience cannot be unique.



  • @fbs7 said in Request for Clear, Public and Reliable Support for Variable Geometries in Poser!!!:

    The API has a way to change the geometry of an actor on the fly - hooray!! That's called SetGeometry(). But it has no documentation of when that can be done, how that can be done, or any recipe for how to do that reliably.

    There are some useful scripts in .../Runtime/Python/poserScripts/CreateProps

    To avoid crashes use <actor>.MarkGeomChanged()

    To manipulate an existing geometry use <actor>.SetVertexCallback(...)
    Description from Poser-Python manual:
    Set a per-update callback to process actor (vertices) while in local deformed
    space. The user-defined function will be called back on each full update of an
    actor and allows for manipulation of the vertices (or other information) at the
    point in the display pipeline of Poser which processes vertex level deformations.



  • Appreciate it; but SetVertexCallback() also crashes if you try to use SetGeometry(). I tried it in vertex callback, world callback and local transform callback, and all of them crash at some time (some faster, others slower). My code is basically this:

    parent = isoSurface.Parent()
    isoSurface.SetParent( scene.ActorByInternalName('UNIVERSE') )
    isoSurface.SetGeometry(isoGeom)
    isoSurface.MarkGeomChanged()
    isoSurface.SetParent( parent )
    

    I tried many kinds of variations in that code - comment the SetParent(), mark the actor invisible before changing geometry then visible again, call Draw() and DrawAll(), create a prop from that geometry, then extract the geometry back from the prop and apply that one (to see if something was uninitialized).

    I was hoping I could plug that in the event handler, but there are no events during animation preview, so that doesn't work.

    As far as I could find, SetGeometry() always crashes if you put it in a callback.



  • Poser is not able to handle a geometry change inside an animation. Only manipulations are allowed. To change this, a lot inside of Poser must be redesigned.

    Maybe removing the prop and recreate it new may work inside an animation (didn't try this yet).

    But a geometry-change at a time when Poser is in the middle of processing the pipeline (VertexCallback) can't work, IMHO.



  • @adp said in Request for Clear, Public and Reliable Support for Variable Geometries in Poser!!!:

    Poser is not able to handle a geometry change inside an animation. Only manipulations are allowed. To change this, a lot inside of Poser must be redesigned.

    Maybe removing the prop and recreate it new may work inside an animation (didn't try this yet).

    But a geometry-change at a time when Poser is in the middle of processing the pipeline (VertexCallback) can't work, IMHO.

    I agree. That's why I think at minimum that needs to be documented in the manual, and the function should fail if it is called in a time when it's unsafe. There's no reference anywhere about what the callbacks can and cannot do. Right now there are 3 callbacks at different points of a mysterious and undisclosed pipeline, with no information whatsoever what they are allowed to do or not, so it's up to trial and error to figure that out.

    At better, an event should be raised in a point outside of the processing pipeline, when it's safe to change geometries, like at the very beginning of the pipeline or when the frame changes. There must be one such point somewhere. And then have it documented clearly that "... at this place and that place it's safe to call SetGeometry() or CreatePropFromGeometry() or etc...".

    As is now SetGeometry() is just an armed bomb with unknown behavior and invisible wires, that the programmer uses at his own very large risk.