Instantiation Via (Poser) Geometry Swapping ?

[Ken1171]

This sounds like something that could benefit from Python scripting to scatter objects at random places inside a given area. The way Octane does it is by placing a rectangle with a greyscale texture to set the "weights". The whiter the area, the more chance a prop will be spawned there. It offers a simple interface to let us set the transform parameters, like scale and rotation variations for each instance, so they don't all look the same. Since Octane will execute the scattering during the next render, we won't see anything happening until then. This is because the instancing happens in Octane, and not in Poser.

However, this seems something that could be done with a Python script over a prop plane that can be placed in the scene. We can use the plane vertices to set probable locations to place the prop instances - not exactly at the vertices, but around them. This would provide a more even distribution, but it could be totally random as well. The script could also add random scaling and rotations to each instance, so they don't look all the same. If done generically enough, it could scatter grass, rocks, plants, or anything else.

The only thing I am not sure about is HOW to create object instances in Poser, instead of just adding a new copy - which doubles the memory load.

 

[DanaTA]

In DS, instancing makes a copy of an object that is tied to that object. You can move it, rotate it, change its elevation, but not it textures. Although, I've recently seen a new product that lets you change the instances appearance, somehow. Instances take up considerably less memory storage than the original object. I've used it once or twice. I made a winter scene with lots of trees and bushes. Only used a few actual objects, then instanced several of each and adjusted their various positions so it didn't look like a forest of clones.

Dana

 

[3dcheapskate]

Very interesting read, Kage! I love playing with things like this to see what can be achieved, and your geometry-swapping prop is definitely an achievement. I have to agree with the above that this is not geometry "instancing", though. There was a time when SMS had announced that Poser now supported instancing, I believe in their early days with Poser, around version 7, and I was enthusiastic about it because it would solve a very old problem - running out of memory.

Instancing has to do with the way memory is allocated when we add a copy of a model that is already on scene. Before Poser 7 (I think it was 7), duplicating the figure on scene would equally duplicate the amount of memory it takes, so we could quickly run out of RAM. Now, you can make an experiment by loading a fully clothed figure with hair and everything, and then using Object->Duplicate with the parent figure selected. Pay attention to how much RAM was used before and after, and you will notice this process no longer duplicates the allocated memory. It increases a bit, but definitely not twice as much. Awesome!

Many 3D programs, and especially game engines, use "instancing" to create a vast amount of copies of the same 3D object, like trees in a forest, using barely more RAM that is needed to load a single copy. 3D rendering engines, like Octane, use instancing to do the same - but only during renders, using the GPU to do it instantly - and using very little memory. Depending on how instancing is implemented, it is often possible to create variations of the same model in memory, like different morphs and sizes (so they don't look all the same), while only storing in memory the differences. Octane render does this by default, offering a panel to let you define how the variations will be created in render-time.

Hope this helps clarifying what instancing is all about - and yes, Poser does support it! ^_____^

Over on the corresponding Renderosity thread ironsoul has an interesting script idea that creates multiple duplicates of a fully clothed figure in different poses (grabbed from different frames of the animation of a single figure, referring to it as 'fake instancing'

 

[3dcheapskate]

This sounds like something that could benefit from Python scripting to scatter objects at random places inside a given area. The way Octane does it is by placing a rectangle with a greyscale texture to set the "weights". The whiter the area, the more chance a prop will be spawned there. It offers a simple interface to let us set the transform parameters, like scale and rotation variations for each instance, so they don't all look the same. Since Octane will execute the scattering during the next render, we won't see anything happening until then. This is because the instancing happens in Octane, and not in Poser.

However, this seems something that could be done with a Python script over a prop plane that can be placed in the scene. We can use the plane vertices to set probable locations to place the prop instances - not exactly at the vertices, but around them. This would provide a more even distribution, but it could be totally random as well. The script could also add random scaling and rotations to each instance, so they don't look all the same. If done generically enough, it could scatter grass, rocks, plants, or anything else.

The only thing I am not sure about is HOW to create object instances in Poser, instead of just adding a new copy - which doubles the memory load.

I'm wondering whether "...using Object->Duplicate with the parent figure selected ..." as mentioned in your earlier post, but called via the Poser API as per ironsoul's observation (linked from my previous post) would do this ?

 

[Ken1171]

To this date I still don't know if Poser handles instancing automatically whenever we duplicate something, or if something more specific is required. The only thing I could do was to duplicate something relatively "heavy", like a fully clothed and textured character, and then observe how that affects memory load. I think textures take way more space in memory than geometry, so that's a factor too. Modern figures use 4K, or even 8K textures in a few cases, and that has a HUGE impact on memory usage. Poser downscales the resolution in previews, and only loads a small bucket of them during renders, and that's how we don't run out of memory so quickly.

Dawn can load as much as 30 textures when a full character with hair and clothes is loaded. Rendering with a 8K or 16K HDRI image can also be a factor. Over here I have 16GB RAM, and rendering a single character with a simple background can take as much as 10GB during renders. In my recent "Hoodie for Dawn" promos, I have rendered 2 copies of Dawn, and if not for instancing, that would probably not be possible.

As for your question, I "assume" that Poser handles instancing when we use Object -> Duplicate. I don't know if we could get the same effect by simply loading the same figure again, and Poser would automatically check if the same geometry is already on scene, and create an instance instead of loading a new copy. Based on memory load observations, it seems that way, though.

 

[kobaltkween]

Ye

Very interesting read, Kage! I love playing with things like this to see what can be achieved, and your geometry-swapping prop is definitely an achievement. I have to agree with the above that this is not geometry "instancing", though. There was a time when SMS had announced that Poser now supported instancing, I believe in their early days with Poser, around version 7, and I was enthusiastic about it because it would solve a very old problem - running out of memory.

Instancing has to do with the way memory is allocated when we add a copy of a model that is already on scene. Before Poser 7 (I think it was 7), duplicating the figure on scene would equally duplicate the amount of memory it takes, so we could quickly run out of RAM. Now, you can make an experiment by loading a fully clothed figure with hair and everything, and then using Object->Duplicate with the parent figure selected. Pay attention to how much RAM was used before and after, and you will notice this process no longer duplicates the allocated memory. It increases a bit, but definitely not twice as much. Awesome!

Many 3D programs, and especially game engines, use "instancing" to create a vast amount of copies of the same 3D object, like trees in a forest, using barely more RAM that is needed to load a single copy. 3D rendering engines, like Octane, use instancing to do the same - but only during renders, using the GPU to do it instantly - and using very little memory. Depending on how instancing is implemented, it is often possible to create variations of the same model in memory, like different morphs and sizes (so they don't look all the same), while only storing in memory the differences. Octane render does this by default, offering a panel to let you define how the variations will be created in render-time.

Hope this helps clarifying what instancing is all about - and yes, Poser does support it! ^_____^

Interesting how no one's arguing with you. When I made an instance manager that duplicated props, figures, etc. I got told I was crazy to believe Poser supported instancing in any respect. I pointed out that top artists like Tomalin have used it for ages rather than making their scenes _so_ much easier to manage by exporting them as one big OBJ to no avail. Didn't matter that I had proof just by being able to render my own work as instances but consistently crashing Poser when I used a single OBJ. So now I have an array/instance manager that can make spirals and such in one click for Poser just sitting on my HD. Good to know that the opposition was personal or identity based rather than unbiased.

Oh, and it manages materials among objects with mat zones that share the same names and such. It just generally makes it easier to both build and manage a set like, say, Aslan Court. It needs refactoring, and I stopped more because the .delete() method crashed Poser after the update before last than because I listened to people who my testing proved were wrong, but I can't say that the constant discouragement telling me that my tool was completely useless didn't have an effect.

 

[KageRyu]

@kobaltkween I do not remember opposing you or calling you crazy. I don't remember the thread or conversation in question.

 

[caisson]

@kobaltkween - you made an array tool?! I would buy it in a heartbeat - it would be useful for building arrays to use with Bullet as well as architectural sets. There was a basic tool with philC's Poser Tool Box but it doesn't work for me anymore. When I made Bag of Bones I found manually duplicating props in Poser can get a bit tedious ... can I persuade you to look at commercial development again??

 

[Ken1171]

Ye

Interesting how no one's arguing with you. When I made an instance manager that duplicated props, figures, etc. I got told I was crazy to believe Poser supported instancing in any respect. I pointed out that top artists like Tomalin have used it for ages rather than making their scenes _so_ much easier to manage by exporting them as one big OBJ to no avail. Didn't matter that I had proof just by being able to render my own work as instances but consistently crashing Poser when I used a single OBJ. So now I have an array/instance manager that can make spirals and such in one click for Poser just sitting on my HD. Good to know that the opposition was personal or identity based rather than unbiased.

Oh, and it manages materials among objects with mat zones that share the same names and such. It just generally makes it easier to both build and manage a set like, say, Aslan Court. It needs refactoring, and I stopped more because the .delete() method crashed Poser after the update before last than because I listened to people who my testing proved were wrong, but I can't say that the constant discouragement telling me that my tool was completely useless didn't have an effect.

I have to say it is not my personal opinion that Poser supports instancing. SMS has announced it during one of the Poser releases as a new feature. I admit I don't quite remember which version that was exactly, but it was listed nonetheless. I can say it's SMS' own fault that confusions like this have happened, thanks to their inability to advertise Poser features in every release. They thought it was good enough to make a bullet list of the new features somewhere in their site, and hope people would notice them. There were times when I saw a feature, but had no clue of what it meant, and the rest of the text didn't explain it either - doing the community (and themselves) a disfavor.

As a result, I didn't understand what Figure -> "Unimesh Skinning" was all about for a whole year after Poser 10 release. That was a MAJOR new feature, but SMS didn't care to advertise it much, even when subdivision depends on it to work. In the same way, I didn't understand at first how instancing would work in Poser, and to be frank, I still don't. I know what it's supposed to do, but I don't know what I have to do to make it happen. Is it fully automatic? Does Poser check to see if the object is already on scene when it loads a new copy? Or instancing only happens when we use Object -> Duplicate? When I search the manual for "instance", nothing comes up. You get the point.

And for .delete() crashing Poser 11, OMG, that was so annoying! Nearly all scripts that deleted something would instantly crash Poser back to the desktop. It took them ages to fix that. Very often I deleted a light, and boom - instant crash to the desktop. It's such a relief that no longer happens.

 

[kobaltkween]

Hope this helps clarifying what instancing is all about - and yes, Poser does support it! ^_____^

To this date I still don't know if Poser handles instancing automatically whenever we duplicate something, or if something more specific is required....
As for your question, I "assume" that Poser handles instancing when we use Object -> Duplicate. I don't know if we could get the same effect by simply loading the same figure again, and Poser would automatically check if the same geometry is already on scene, and create an instance instead of loading a new copy. Based on memory load observations, it seems that way, though.

It's odd that you're backing off your previous statements. Not sure why that is.

Well, again, it's kind of easy to test. You've already shown that scene-wise, instances take up less memory. Try to render an untextured high poly obj as a single OBJ or as multiple instances of the same OBJ. For me, one crashed Poser immediately, thoroughly, and every single time, while the other renders just fine the whole way through, no memory issues or crashes. IMHO, the proof is in the pudding. And in this case, if you don't want the pudding to make people's computers vomit, it's better to use instances in your work than to export one big OBJ file. Which I'm guessing is at least part of why Tomalin, Merlin Studios, Stonemason, and other top scenery artists used this method. Back when they made stuff for Poser, that is.

To be very frank, I didn't care at all about instancing or not when I made the tool. I cared about not being able to use all this really high quality stuff I bought because it took me literally hours to fix all their materials and manage their scenes (for instance, delete all of a certain prop in a hierarchy repeated throughout a scene- for instance, a lantern parented to all instances of an archway). I also made it because it was taking me too long to test your Savage Weapons. Deleting the multiple arrows was a PITA without it, but I never would have suggested just making them into one OBJ instead.

That was actually the thing that made it so exhausting, actually. I was trying to focus on working on an array tool, but I got stuck in a very long argument about why people who are frankly more accomplished content creators than I tend to use them rather than one big OBJ. It was tiresome and discouraging and utterly beside the point.

I will say that 1) I think the aspects of rendering that Firefly handles weirdly, like IDL and SSS, get calculated in a way that instancing doesn't help because it's view based, and that 2)SF/Cycles seems to try to ignore what's not in the render anyway.

It will be interesting to see what happens when/if they update SF to current or even recent Cycles functionality.

 

[kobaltkween]

@kobaltkween I do not remember opposing you or calling you crazy. I don't remember the thread or conversation in question.

Oh, no, you weren't a part of that. Not directed at you at all. At least one person told me very explicitly that I was solving a problem that didn't need solving and there was no need for a tool to manage arrays or materials across objects in Poser. And then posed figures to "prove" that instancing wasn't a thing because they could take different poses. It didn't matter how many times I was like, "Yes, instances can have different parameters, and posing is just a set of parameters for body parts. I can do the same with figures in Blender, which definitely does support instances. In fact, there's whole crowd simulation tools for Blender using this principle." All I got was flack, and absolutely zero encouragement.

 

[Ken1171]

Hey, I wasn't backing off above - I was just saying I don't know when instancing happens in Poser. I know it does support it, but not what causes it to kick in. I do know I can easily run out of memory in renders (I have 16GB) with a single character if it uses many large textures, many morphs, and/or heavy geometries. I assume instancing helps with geometry, but textures and morphs can take way more RAM.

 

[kobaltkween]

I'm wondering whether "...using Object->Duplicate with the parent figure selected ..." as mentioned in your earlier post, but called via the Poser API as per ironsoul's observation (linked from my previous post) would do this ?

Yeah, that's how you script duplicating. You actually call the function from the interface, IIRC. It's been more than a year, so I'd need to go over the code again.

 

[kobaltkween]

I have to say it is not my personal opinion that Poser supports instancing.

Hey, I wasn't backing off above - I was just saying I don't know when instancing happens in Poser. I know it does support it...

Ummmmmm..... You literally just said it's not your opinion that Poser supports instancing. Previously you said it did, and now you're saying you know it does. I'm kind of confused.

And I never said anything about the argument being about it being "when," or any of the details. The argument, explicitly and adamantly, was that Poser does not support instancing in any way, shape, form, etc., and that there is no such thing as a "Poser instance." It was not about my methods. It was about my goal. They claimed that an array tool for Poser was completely useless and unnecessary and completely stupid because Poser did not support instancing, period.

And again, I'm just noting that some people state their technical knowledge and there's no argument. Conversely, for instance, I have had people who say they were new to learning dynamics tell me that I didn't know what I was talking about involving dynamics when I literally and explicitly quoted the manual.

 

[Ken1171]

The thing about "when" instancing happens in Poser was my own argument in the first post. Maybe you have missed it? As the quote above, I said it was not my personal opinion because SMS has officially claimed Poser supports instancing. That's all I was saying - I know Poser has instancing because SMS said it, not because I think it does. Maybe you have misunderstood me?

I was already saying from the very beginning that I don't know "when" instancing happens in Poser. I just said it again, and for some reason you thought I had changed my mind about it. If you pick quotes out of content, it may lead to misunderstandings.

 

[kobaltkween]

The thing about "when" instancing happens in Poser was my own argument in the first post. Maybe you have missed it? As the quote above, I said it was not my personal opinion because SMS has officially claimed Poser supports instancing. That's all I was saying - I know Poser has instancing because SMS said it, not because I think it does. Maybe you have misunderstood me?

I was already saying from the very beginning that I don't know "when" instancing happens in Poser. I just said it again, and for some reason you thought I had changed my mind about it. If you pick quotes out of content, it may lead to misunderstandings.

Oh, I see what you mean. No, I read your statements through, but I thought you were saying that SMS were just lying and obfuscating in the middle post. That your opening sentence meant your personal opinion differed, and their lack of clarity on it was proof of deception, not that you were working from their statement, not opinion. I apologize for misunderstanding you.

My point about the "when" part is simply that it wasn't relevant to the debate I had before. I get (and already got) that you've been going over that aspect. It's an interesting topic, but it's kind of beside my issue, which is simply, "Do instances have a benefit in Poser?"

Logically, I'd think that if you load something from a preset that points at an OBJ rather than embed geometry in a preset, the software is aware of the loaded OBJ file. But that's just an assumption. I can say that the duplicating you can do by scripting and that you can do with the interface are one and the same. You have to use the ProcessCommand method.

 

[Ken1171]

Well, that's one thing I know for sure - embedded geometry will not benefit from instancing. In most cases, vendors will provide a linked OBJ. It's a shame Poser keeps embedding geometry in props by default. That is not accepted in any store I know of, and loading more copies will use more memory (AFAIK). I have to use 3rd party scripts to save stuff to the library properly. It amazes me we are in version 11, and Poser still has no clue where to place geometry files. It could just ask, or use metadata, but no - it just dumps it at the wrong place - you fix it. If you ask me, I'd rather have these basic things fixed than to have more new features.

 

[kobaltkween]

@kobaltkween - you made an array tool?! I would buy it in a heartbeat - it would be useful for building arrays to use with Bullet as well as architectural sets. There was a basic tool with philC's Poser Tool Box but it doesn't work for me anymore. When I made Bag of Bones I found manually duplicating props in Poser can get a bit tedious ... can I persuade you to look at commercial development again??

Yeah, you definitely could. It's not a scatter tool, which I want to make eventually but am not entirely sure how to, but it does have a material manager that should be useful even on its own. Nothing fancy or complex, just copying current node trees to others. Let me see what it will take to refactor and give it a proper interface that doesn't need me to switch out its functionality by hand.

Well, that's one thing I know for sure - embedded geometry will not benefit from instancing. In most cases, vendors will provide a linked OBJ. It's a shame Poser keeps embedding geometry in props by default. That is not accepted in any store I know of, and loading more copies will use more memory (AFAIK). I have to use 3rd party scripts to save stuff to the library properly. It amazes me we are in version 11, and Poser still has no clue where to place geometry files. It could just ask, or use metadata, but no - it just dumps it at the wrong place - you fix it. If you ask me, I'd rather have these basic things fixed than to have more new features.

Oh, definitely. On all counts. IMHO, there's a whole lot of aspects to Poser that would get used regularly if the interface simply supported how people create content and use communal content rather than worked against them.

 

[3dcheapskate]

Going back a few steps, to ken1171's comments about how much Poser's memory use increases when you add several identical items - I tried that over the weekend. I'm using PP2014 on a Win 10 laptop, and after each step I waited until Poser's memory use (according to task manager) had settled down to what appeared to be a stable figure:
1) Opened PP2014 to a simple scene (2 lights, no figures,no props): Poser memory use (once stabilized) = Around 275MB
2) Loaded a clothed, textured, morphed, posed V4 from a CR2: Poser memory use (once stabilized) = Around 850MB (i.e. an extra 575MB)
3) Loaded a second identical figure from the CR2 in the library: Poser memory use (once stabilized) = Around 1275MB (i.e. an extra 425MB)
4) Loaded a third identical figure from the CR2 in the library: Poser memory use (once stabilized) = Around 1710MB (i.e. an extra 435MB)

I then restarted Poser, did exactly the same for (1) and (2), but for (3) and (4) I used Object > Duplicate instead of loading a new figure from the CR2. Poser's memory use was near enough identical to the figures already noted

That seems to indicate that the second and third figures each require only 75% of the memory that the first figure did, regardless of whether you load a new figure from a CR2 or duplicate the existing figure. At least for this specific case. That doesn't seem to be much of a reduction to me. If 'instancing' (of any form or definition) was happening I'd expect (and remember that I don't really know what I'm talking about here!) a far more significant reduction for the 2nd/3rd figures.

...
Logically, I'd think that if you load something from a preset that points at an OBJ rather than embed geometry in a preset, the software is aware of the loaded OBJ file. But that's just an assumption. I can say that the duplicating you can do by scripting and that you can do with the interface are one and the same. You have to use the ProcessCommand method.

1568 ? ironsoul's script (which he referred to as 'fake' instancing over on the corresponding Renderosity thread) uses poser.ProcessCommand( 1568 ). So if that API call is the same as the UI Object > Duplicate then I'd expect Poser's memory usage to be the same as the figures already noted (although I haven't tried it)

 

[caisson]

@kobaltkween - that is good to hear, hope it's a smooth process. A material manager that is up to date with the new nodes (including compound nodes) would be really useful too. For scattering, I could post ideas based on how other tools I've used have worked if that would be any use!