Over at Hivewire there's a comment that "...There was a time when SMS had announced that Poser now supported instancing, I believe in their early days with Poser, around version 7..." (3rd sentence of 1st paragraph here)

Does anybody recall this ?

I remember there was a script by PhilC which made arrays (is that a sort of instancing ?) and then the Python updates kind of made the scripts freeze.

Array scripts were mentioned over on that Hivewire thread, but that's not what I'm wondering about.

Apparently SM officially (around the time of Poser 7 possibly?) announced/stated/mentioned that Poser now supported instancing. Although exactly what was meant is unclear. Especially as there appears to be no trace of the announcement/statement/mention. I was wondering,since Renderosity/Bondware now own Poser, whether anybody here knows (or can dig up) anything about that.

Instancing in poser is limited to .obj and textures. Poser does not reload either of these if there is already one cached with the same name. That is why most stores require props to have external geometry, otherwise each copy in a scene would create a new obj in memory.

So if I load 2 V4's in a scene with the same texture, there is only one copy of the obj and the textures in memory. What can not currently be instanced is all of the other information, location, morphs, scale etc. A fully loaded V4 with external geometry still will take up 100's of megabytes of memory for each copy

Bill

That would confirm my own testing with a sequence of one and up to ten SASHA's then! Thank you for the additional insight @willyb53: I wish you would comment more often!

K

willyb53 posted at 8:15AM Thu, 02 April 2020 - #4385120

Instancing in poser is limited to .obj and textures. Poser does not reload either of these if there is already one cached with the same name. That is why most stores require props to have external geometry, otherwise each copy in a scene would create a new obj in memory.

So if I load 2 V4's in a scene with the same texture, there is only one copy of the obj and the textures in memory. What can not currently be instanced is all of the other information, location, morphs, scale etc. A fully loaded V4 with external geometry still will take up 100's of megabytes of memory for each copy

Bill

Thanks Bill. That explains a lot. Do you know if that was ever officially documented, e.g. in the Release Notes for a specific version of Poser ? Or failing that are you aware of any threads discussing it around the time it was added (although I guess they would have been on the RDNA forums)

Even better, that would indicate that the geometry-swapping scatter figure that I'm messing around with with is actually using instancing :)

willyb53 posted at 11:06AM Thu, 02 April 2020 - #4385120

Instancing in poser is limited to .obj and textures. Poser does not reload either of these if there is already one cached with the same name. That is why most stores require props to have external geometry, otherwise each copy in a scene would create a new obj in memory.

So if I load 2 V4's in a scene with the same texture, there is only one copy of the obj and the textures in memory. What can not currently be instanced is all of the other information, location, morphs, scale etc. A fully loaded V4 with external geometry still will take up 100's of megabytes of memory for each copy

Bill

Hmmm... one of the tests I did over on the Hivewire thread now puzzles me, as the 2nd and 3rd 'instances' each use 80% of the memory of the 1st 'instance', which was an imported OBJ with no textures.

Look at the size of a CR2 compared to the object file it points to. The data for the obj is small compared to all the channels of data needed to keep track of where the arm is and the hand etc. So you don't have the data that defines the mesh, but you do have it for how the mesh will be formed.

Removing those channels from the figure will have a big impact on screen redraw speed and allow for more duplicates from the point of view of working with the scene. Maybe need a figure to prop function as part of the process. Propagation of changes from the master to the instances is another element that could be considered a quality of instancing, so if the pose of the master figure, morph or shader changed it would also appear in the instances. Not sure how to do this, thought was to delete and reinsert the duplicates, maybe Poser has an inbuilt feature to make this easier.

Richard60 posted at 2:59PM Thu, 02 April 2020 - #4385168

Look at the size of a CR2 compared to the object file it points to. The data for the obj is small compared to all the channels of data needed to keep track of where the arm is and the hand etc. So you don't have the data that defines the mesh, but you do have it for how the mesh will be formed.

Agreed, for the cases where there's a CR2. Which was every case except the specific one I was thinking of, which used just an imported OBJ - no CR2 involved.

(I should probably have made that more clear - clarity is not one of my strong points! ;) )

If its possible to modify the geometry via Poser API it would be interesting to see if modifying the source prop used in the geometry swap also modifies all the instances.

An "Imported Obj" is not a well-defined phrase but my first inclination is to presume you used the OBJ Import dialog. In which case, a prop with its own geometry was created in memory, no reference to the Obj file, which can now be deleted - a thing I've done a thousand times. So if you clone that imported obj, you are making full copies of it, not instances that all refer to a common, single "loaded obj". What I'm saying is "loaded obj" is shared, "imported obj" is not.

Correct, I used File > Import > Wavefront OBJ - so that would be similar to loading a PP2 with embedded geometry ? Not what I'd intended.

To make my test valid I need to do File > Import > Wavefront OBJ, save that as a PP2, remove the embedded geometry from the PP2, and point the PP2 to an external geometry instead.Then I can load the PP2 and Edit > Duplicate, and that should give more meaningful results.

If you want to get technical Then Poser's Hair Room has instancing in that you have a couple of hundred strands that you can move about and then populate then rest with clones that come and go. Not helpful for anything except the hair room, but it does sort of exist.

willyb53 posted at 11:58AM Thu, 02 April 2020 - #4385120

A fully loaded V4 with external geometry still will take up 100's of megabytes of memory for each copy

Bill

There are ways around that. I have a base V4 with all morph packs and corrective morph packs - she runs at around 500Mb. I have one of these for each base mesh that I use.

When I make a character, I first strip out all of the unused morphs (1 click). Then I use the "Dials to FBM" command to make a final FBM (1 click). Then I strip out the PBMs that made up the FBM (1 click). Make an injection of the FBM (1 click). Load FBM into a base mesh with only expressions and it is done (1 click).

Now he/she is less than 100Mb. If he/she is a regular character (as opposed to a "red shirt"), I'll put him/her into a uniform (M4 Valiant or V4 Courageous that has been run through the fitting room) merge the figure and then use the Reduce Polygons command to shrink it even further.

It is also a lot faster than it sounds (less than 5 minutes from start to finish) - l love python scrips in Poser

ironsoul posted at 9:31AM Fri, 03 April 2020 - #4385183

If its possible to modify the geometry via Poser API it would be interesting to see if modifying the source prop used in the geometry swap also modifies all the instances.

I've asked Ken1171 over at Hivewire if he can try this, although he's not using geometry swapping, just Python.

3dcheapskate posted at ?:??AM ???, ?? ??? 2020 - #4385188

Correct, I used File > Import > Wavefront OBJ - so that would be similar to loading a PP2 with embedded geometry ? Not what I'd intended.

To make my test valid I need to do File > Import > Wavefront OBJ, save that as a PP2, remove the embedded geometry from the PP2, and point the PP2 to an external geometry instead.Then I can load the PP2 and Edit > Duplicate, and that should give more meaningful results.

Tried that yesterday. Still got big numbers for the 2nd/3rd figures (Empty scene=285MB, 1 figure from PP2 (ext geom)=505, 2nd (Edit>Duplicate)=697, 3rd(duplicate)=889,4th (duplicate)=1150. I accidentally closed windows Task Managerat this point. When I reopened it it showed Poser's memory use at around 400MB.

I don't trust Windows Task Manager at all now.

I'm suspicious about Edit/Duplicate - it might be implemented as copying all the mesh info into a new instance. If there's any hope to shared mesh data it would be by loading the identical PP2/obj combo multiple times.

On the alternate geometry subject, my understanding is that it is implemented via a uniqueInterp(olated) channel on the actor (essentially locked to integer values, rather than a float)

Here's one use I found from my efforts way back in the dawn of time, when folks first crawled from the primordial slime...

actor rThumb2:38
    {
    name    rThumb2
    on
    bend 1
    animatableOrigin 0
    dynamicsLock        0
    hidden      0
    addToMenu   1
    castsShadow     1
    includeInDepthCue       1
    useZBuffer      1
    parent rThumb1:38
    conformingTarget rThumb2:1
    alternateGeom    rThumb2_1
        {
        name Hidden rThumb2
        objFile 20 :Runtime:Geometries:Null.obj
        }
    creaseAngle 80
    subdivLevels 0 
    subdivRenderLevels 0 
    subdivideWithFigure 1 
    channels
        {
        geomChan PBMHideFingers
            {
            uniqueInterp
            name PBMHideFingers
            initValue 0
            hidden 1
            enabled 1
            forceLimits 1
            min 0
            max 1
            trackingScale 1
            keys
                {
                static  0
                k  0  0
                sl  1
                con
                sm
                }
            interpStyleLocked 0
            valueOpDeltaAdd
                Figure 38
                rHand:38
                PBMHideFingers
            deltaAddDelta 1.000000
            }

This use was prior to the implementation of animated visibility for actors, so the only way to completely hide something (other than scale it to atomic proportions) was to swap out its geometry for a null. The geomChan can then be slaved via value operations (ERC). If such was done with "instanced" props, they can all follow the master's geometry changes. If they are all loaded (not imported) from the same obj file as mentioned, that should minimise memory usage. It's been a while since I tested this, as geometry swapping did not play nicely with unimesh figures at some point. (or maybe it was just one figure with dodgy geometry that couldn't be subdivided. I'll have to check my logs)

Taking a couple of steps back, I'm particularly interested in the bit Ive highlighted in bold below.

ssgbryan posted at 11:50PM Fri, 17 April 2020 - #4385234

willyb53 posted at 11:58AM Thu, 02 April 2020 - #4385120

A fully loaded V4 with external geometry still will take up 100's of megabytes of memory for each copy

Bill

There are ways around that. I have a base V4 with all morph packs and corrective morph packs - she runs at around 500Mb. I have one of these for each base mesh that I use.

When I make a character, I first strip out all of the unused morphs (1 click). Then I use the "Dials to FBM" command to make a final FBM (1 click). Then I strip out the PBMs that made up the FBM (1 click). Make an injection of the FBM (1 click). Load FBM into a base mesh with only expressions and it is done (1 click).

Now he/she is less than 100Mb. If he/she is a regular character (as opposed to a "red shirt"), I'll put him/her into a uniform (M4 Valiant or V4 Courageous that has been run through the fitting room) merge the figure and then use the Reduce Polygons command to shrink it even further.

It is also a lot faster than it sounds (less than 5 minutes from start to finish) - l love python scrips in Poser

Do you have a list of the specific scripts you use ?

willyb53 posted at 11:58AM Thu, 02 April 2020 - #4385120

A fully loaded V4 with external geometry still will take up 100's of megabytes of memory for each copy

Whenever I see references to figures taking up "memory," I always wonder: are you talking about hard disk space or RAM? I might be wrong about this, but I don't think there's a one-to-one correlation between MBs used on disk and amount of MBs taken up by RAM. At least, I've never seen that correlation in all my years of studying the Activity Monitor on a Mac!

ssgbryan posted at 1:31AM Tue, 21 April 2020 - #4385234

When I make a character, I first strip out all of the unused morphs (1 click). Then I use the "Dials to FBM" command to make a final FBM (1 click). Then I strip out the PBMs that made up the FBM (1 click). Make an injection of the FBM (1 click). Load FBM into a base mesh with only expressions and it is done (1 click).

Now he/she is less than 100Mb.

This is a bit off-topic for the thread, but I've always wondered what might be lost by consolidating all V4 character morphs using the "Dials to FBM" tool (which I think is part of the Wardrobe Wizard suite of useful tools unrelated to wardrobes!?) I tried it a few years ago, and I found that some things (most likely corrective morphs and expressions) didn't work as I expected them to b/c they were, apparently, depending on some specific character morphs (most likely Aiko4) that had been removed after I did the "dials to FBM" thing. So I haven't tried it again.

But otherwise I do something similar to what you describe, in that I have a fully loaded V4 (a Sasha-16 version) I use as a "starter" for designing a character, so I can fiddle with all the morphs to see what works best. She has A4, G4, S4, Elite, Aged, Faerime, Facial Expressions, Distinctive Features, and probably a few more, but not She-Freak or Creature b/c I haven't yet had a need for those. Once I've settled on the new character's face and body shape, I save a pose file with the shape info and take notes on which morphs I used so that I can inject only those into a base V4. Then I apply the pose file and save the new character (averaging around 90-120 MBs, depending on which morphs I used).

I've been hesitant to go one step further and condense all the shape morphs into one "dials to FBM" solution b/c I don't want to limit the figure's functionality. Have you not found that to the be the case? I suppose I could give it another try, at least for more minor character, as I continue tweaking my main characters' shapes indefinitely! (and I sometimes use shape dials to deal with pokethrough or weird pose-related issues)