Quote - In either case, I'm not going down the rabbit hole of feature-countings, because it's obvious that some folks want it packed, and damn the consequences.

I'm not convinced there are consequences, certainly none that make the program harder to use for a beginner.  Cloth and set-up, for example, have their own rooms, so if you aren't ready to use those, the tools aren't presented to you if you stay out of them.  Things like mutiple undo/redo and multithreaded rendering don't require presets (unless you count a "checkbox" as a preset) and I'd wager most people do use them and would be asking for them today had they never been implemented...

Maybe, because I entertained the idea of a basic paint tool, you think I want every feature including the kitchen sink to be added.  I don't.  I don't think Poser needs general purpose modeling tools or video editing, for example.  Soft-bodies seem to me a very standard function in a figure posing and animation tool, so I will be requesting that feature until it is added.  If you aren't to the level where that function would benefit you, then I can only hope it is never in your way.  Lack of soft bodies is limiting other users too, as I'm certainly not the only one asking for it.

What frustrates me about these discussions is that I never once said we don't need more (and better) figures.  I merely said that I hadn't seen unneccesary features being added to Poser in particular, and that better figures would not address my particular needs, while IK/FK blending and soft bodies (or a spring solver) actually would.  When Pixologic announced that zBrush would be getting animation features, there were similar complaints from users that it was unecessary, a waste of development resources, that it would clutter the program unnecessarily, etc.  These were the users who were using zBrush to sculpt and model figures for animation, which was never zBrush's purpose to begin with.  They felt that they were the majority and all development should be focused on their needs alone.  It didn't matter to them that the tools they use hadn't always been there, and Pixologic wanting to broaden their program's appeal is their right as it is their business. 

By all means, be vocal about what you would like to see added to Poser (though it seems as if many here would have indeed been fine to stop upgrading at version 6), but when you criticize a feature you don't use, or dispute the need for a feature another user requests, you are potentially affecting other paying customers.  I wouldn't want SM to stop developing better figures, why then would you want them to stop improving the actual program?

On the subject of experience bias, I was contacted last year and told I should talk to a group of researchers working for a government agency in my town.  A short time later I was under contract to produce a Poser scene and a significant number of accompanying poses.  I worked on this steadily for several months, and am only now finishing the project (at gov't speed).  I used the P4 Casual Male figure as a base, and modeled all but one of the props myself.  I have no doubt that there are many others like me who use Poser in research, academia, and other fields and who are more concerned about the core functions of the program than which figure has the most items in her wardrobe.  Maybe we are a minority, but we pay for the program too.

Quote - The main problem still hasn't disappeared, though: The majority of the Poser-using market is heavily reliant on a 6-year-old mesh that Smith Micro doesn't have any influence or control over.

That is a wholly valid concern, but without knowing SM's business model for Poser I don't know whether it puts them in a dangerous position or not.  I'd have to know if content sales are being used to sell Poser at a loss such as Daz do.

Quote - I should have said, if the figure was weight mapped too. The figure in that image is Cookie and she isn't weight mapped.

I've just thought of something else I'd like in Poser. I like the cloth room but sometimes click on the setup room instead and turn the prop into a figure by mistake. It would be good to have an option not to do that.

It would also be good to have some of the windows resizable such as the export window etc. These are just cosmetic improvements but they would make the interface more user friendly. Overall though I am happy with the way Poser is progressing.

Could you give me a step by step on how you turn a prop into a figure in the cloth room?  I really would like to do that with some props I have.

Quote - > Quote - I should have said, if the figure was weight mapped too. The figure in that image is Cookie and she isn't weight mapped.

I've just thought of something else I'd like in Poser. I like the cloth room but sometimes click on the setup room instead and turn the prop into a figure by mistake. It would be good to have an option not to do that.

It would also be good to have some of the windows resizable such as the export window etc. These are just cosmetic improvements but they would make the interface more user friendly. Overall though I am happy with the way Poser is progressing.

Could you give me a step by step on how you turn a prop into a figure in the cloth room?  I really would like to do that with some props I have.

I think Janl was referring to the set-up room turning the prop into a figure when entering it by mistake. 

Quote - I think Janl was referring to the set-up room turning the prop into a figure when entering it by mistake. 

That's right. Just entering and exiting the setup room turns a prop into a figure and if you do it by mistake you are doomed. :lol:

I just want clothes to inherit every morph that is loaded on the figure so that when I shape it the clothes follow because they have the exact same morphs. Maybe fuse Morphing Clothes app with poser? Or get WW to automate the morphs transfer process. I'm tired of having to open morphing clothes and doing manual transfers. I see the ideal workflow like this - Just load figure, click on clothes, app/poser does automatic quick transfer of all figure morphs to clothing item, and done.

Quote - I have no idea why penguisto has to turn this into a personal attack. I was nowhere bashing anyone, just commenting on some of the remarks others made.

Yeah, no shit. I believe I asked what ppl would like here on in from POSER, not the finer points of the Daz/Poser rift and what it has to do with the price of oil. Whatever. Always a shit tossing contest.

Laurie

I agree that adding the morphing clothes functionality to poser would be an incredible step forward.  I'm not sure it 'needs' to happen automatically (or even if thats currently possible for poser) but just being included would be a big counter to what I think is the most compelling feature of DS4/Genesis

Quote - I just want clothes to inherit every morph that is loaded on the figure so that when I shape it the clothes follow because they have the exact same morphs. Maybe fuse Morphing Clothes app with poser? Or get WW to automate the morphs transfer process. I'm tired of having to open morphing clothes and doing manual transfers. I see the ideal workflow like this - Just load figure, click on clothes, app/poser does automatic quick transfer of all figure morphs to clothing item, and done.

Quote - > Quote - I have no idea why penguisto has to turn this into a personal attack. I was nowhere bashing anyone, just commenting on some of the remarks others made.

Yeah, no shit. I believe I asked what ppl would like here on in from POSER, not the finer points of the Daz/Poser rift and what it has to do with the price of oil. Whatever. Always a shit tossing contest.

Laurie

If only I didn't have to sleep.

The personal attacks seem to have subsided. Please people... I'm just back from a trip to the ER overnight. I don't need to have to start bitching people out feeling the way I feel.

Please honor LaurieA's request made in her first post: The lady said up front, she does not want this to be about Daz bashing. Let's keep the thread about WHAT YOU WANT FROM POSER and stop trying for Alpha Male positioning. And there have been SEVERAL guilty of that behavior. You know who you are.

Quote - I agree that adding the morphing clothes functionality to poser would be an incredible step forward.  I'm not sure it 'needs' to happen automatically (or even if thats currently possible for poser) but just being included would be a big counter to what I think is the most compelling feature of DS4/Genesis.

The combination of WW and MC builtin would be the ultimate in convenience and workflow for me. I have both programs, but the fact that I don't have to leave Poser to make WW work is a big plus for my workflow. Not sure what it would cost, but it's a dialogue that Smith Micro might be interested in having.

Hehe...hey basicwiz...might wanna mark ur post for language there were you quoted me and my potty mouth...lol.

Laurie

ROFL

I'll have to issue myself a TOS warning.

Quote - ROFL

I'll have to issue myself a TOS warning.

Lemme know how that turns out...lolol.

Laurie

About the same as with the other warnings I issue around here.

Nada.

Back to the subject at hand here.... lol...

If I already went over some of this forgive me.

Metaballs... nuff said on that.

One more weight map channel per joint, Bone Centerline Offset with two animatable bulge maps and all maps effected by/with metaballs. (Tall order, but more than worth it.)

Quote - > Quote - I agree that adding the morphing clothes functionality to poser would be an incredible step forward.  I'm not sure it 'needs' to happen automatically (or even if thats currently possible for poser) but just being included would be a big counter to what I think is the most compelling feature of DS4/Genesis.

The combination of WW and MC builtin would be the ultimate in convenience and workflow for me. I have both programs, but the fact that I don't have to leave Poser to make WW work is a big plus for my workflow. Not sure what it would cost, but it's a dialogue that Smith Micro might be interested in having.

For me, WW in Poser is the ultimate inconvenience to my workflow.  Let me explain....

When I use WW that is built into Poser, I can't do anything until it is finished.  The built-in WW is tied to the main Poser thread.  There have been times it has taken several hours to finish analysing a piece of clothing and when that happens, I am done for the evening.  The bad news is PhilC has apparently stopped development of the stand-alone version & this irritates me to no end.

Since Morphing Clothes is a seperate program, I can  Tab to Morphing Clothes, start it working in the background and Tab back to working in Poser.  I like that functionality.

If these items could be spun off onto seperate threads like the renderer, I would consider it. 

Just like my computer - I can multitask.

Quote - If these items could be spun off onto seperate threads like the renderer, I would consider it.  Just like my computer - I can multitask.

You know, You are right! I never had WW stand alone, so I never even thought about how convenient it would be to allow it to run separately. (A man born with one hand knows no other way to tie his shoes.)

Upon reflection, I'm going to jump to your view. Any separate functionality merged into the program would be far more convient if it could be spun off into a separate thread. Wonder if that could be done with the builtin Wardrobe Wizard?

Quote - > Quote - If these items could be spun off onto seperate threads like the renderer, I would consider it.  Just like my computer - I can multitask.

You know, You are right! I never had WW stand alone, so I never even thought about how convenient it would be to allow it to run separately. (A man born with one hand knows no other way to tie his shoes.)

Upon reflection, I'm going to jump to your view. Any separate functionality merged into the program would be far more convient if it could be spun off into a separate thread. Wonder if that could be done with the builtin Wardrobe Wizard?

Depends on how they use python - which is probably why it could be integrated into Poser in the first place. 

just jumping in...

the issue holds for a lot of functions. WW, Cloth Room Sims, Rendering, and so on. The point is... SM "should" turn Poser into a Multi-Document application so one can be processing in the background while working on the other.

For this purpose, I run PPro2010 and PPro2012 simultaneaously in different scenes. Or Poser and Vue. Or Poser and ...

He he, on this point of hiding the more complicated UI / features from "non-advanced" users... seriously... surely if someone buys Poser Pro... or indeed Poser 9, they'd like to at least know they have the capablities featured.

Otherwise they'd just get Debut... or download some freebie or other.

But yes please to more multi-threading, per the most recent posts.

Is there a reason that IDL and Ray tracing passes are apparently limited to not much more than 25% of my i7 quad core capability (when SSS consumes everything it possibly can) ...under OS X.

Re-nicing the processes doesn't seem to help...

But it can't be cpu to memory ratios if SSS consumes the whole CPU potential, can it?

Sorry... sliding off topic here and rambling. LOL... and I should probably install SR2.1 before pursuing this point further... likely back in that Rdna thread I started on this...

wonders off, scratching head

;-)

@monkeycloud: I just tested on my 6-core Windows using Tmonitor from CPUID as well (don't know if there is something similar for mac).. Got similar numbers from taskmanager but:

• those processes are a mix of singe and multi thread steps, so you'll get average numbers for the mix. The launcher for the multi-threading is always single threaded by itself (like: there is always only one manager process in queue/network rendering).

• the multi thread parts are definitely present, but very short in individual length (say 0.2 sec each). I could see that in Tmonitor, which reports at 20 views per second. Each CPU thread gave about 1 burst per sec.

• the taskmanager reporting steps are larger (high speed = 0.5 sec, normal = 1 sec), so you'll get a single/multi-mix average over the period. Some math: 100% load at 20% of the time + 8% load (I've got 12 CPU threads) x 80% of the time = 26% load average.

Thanks aRtBee... at some point soon I will try logging some more formal stats on what I'm getting.

I was referring, largely, to just using the Background Render option in fact there... which does get me somewhat more CPU priority (and therefore a faster render output) seemingly, in general, than QM.

In fact, for a scene with less content (memory consumption) the CPU can seem to stay at 75% or more (overall usage) for the whole render process.

So the issue of it dropping down to just around the 25% mark for the IDL and Ray Trace / Render portions, seems to be linked to a scene being larger (e.g. memory and virtual memory each sitting around the 3 to 4 gigabyte mark)

I'm just unclear I guess as to why this would be the case for the first and last passes, but not for the interim SSS pass...

...anyway, entirely off-topic I think for this thread... so please ignore... I'll post separately somewhere in due course I expect... although I should try the SP2.1 update first really, in case there's a difference ;-)

One thing to be careful of when attempting to observe CPU use and deduce whether it is single or multi threaded:

Even a single thread jumps around from one CPU to another - the OS does this to distribute heat more evenly. If a very busy thread stays on just one CPU that part of the chip heats up.

So - just because you see multiple CPU involved over some short period of time doesn't prove it is briefly multithreaded.

If the reported total utilization is around 25% on a quad core, it is almost certain (or at least far more likely) that the process is completely single threaded, even if it seems to use all 4 cores or 8 hyper threads.

Ah, okay... that makes sense, BB... thanks.

So, does this suggest that (what I'm guessing are) the ray tracing related stages of the rendering process are currently somehow still single threaded... at least in part?

This seems unlikely doesn't it? Surely ray tracing by its very nature is one of the ideal applications for scaling up to / exploiting a multithreading and multicore system?

So, should the process be multithreaded, but for some reason... due to my settings perhaps, or a system resource limitation elsewhere, they're not able to be multithreaded???

Unless OS X is throttling it for some reason I guess... that might be the other explanation.

But, if I compare rendering with Vue... the render engine there consistently uses anything up to just short of the full 100% of total CPU, if that's available to it (no other apps running).

EDIT: But so too does Firefly, apparently... use the full percentage... when rendering a smaller scene... making me go back to suspecting a related resource limitation, e.g. memory...

I'm not yet tanked on my morning coffee, so I have some level of built-in confusion.

You speak of a ray-tracing pass or something, that is limited to single thread. I'm not aware of such a pass.

There is the IDL pass.

There is the scatter pass.

Then there is the beauty or final render pass.

I have never noticed these avoiding 100% CPU use, but that doesn't mean it didn't happen - it means I didn't notice. What you describe is news to me. I see that you qualified it as happening only in a scene using a lot of RAM. I never do that as I am not an artist - or if I am an artist then my signature style is one light, one prop.

I will investigate what my computer does with Poser threading, but it may reveal nothing interesting.

Thanks BB

He he.. I've already lost count of my coffee intake today... but the confusion is still there ;-)

Yup, as I say, when I render a more lightweight scene, or probably anything up to average... it seems to quite happily eat up around 650% to 700% of hyperthreads (of the 800% total)... for all three passes, IDL, SSS and final render pass.

So, the "problem" does seem only to present itself once a scene has gone beyond a certain level of complexity. I guess maybe in terms of figure count... or perhaps light count.

I never use a lot of lights... but for instance I'm doing a scene at the moment and this was, I recall now, rendering at full pelt when just IDL with envsphere (no lights).

So... thinking about it, it's only since adding some point lights and a couple of spots to it, that I've noticed the 25% constriction apparently manifest...

...thinking about it I have added about six points now... where the real lights are in the set I'm using...

...so that's interesting. I will experiment some more too I think...

actually.. the biggest thing I think I'd like to see..

the OBJ import Smudge being fixed!

Quote - You speak of a ray-tracing pass or something, that is limited to single thread. I'm not aware of such a pass.

Yes... I was making an unqualified assumption that the IDL pass and the final render pass both involved aspects of the ray tracing engine, whereas the SSS pass didn't?

in my opinion

• when I see CPU % bounce between 15 and 35%
• when I see Tmonitor reporting 0.2 sec = 4 consecutive bars + thread overclock peaks on all CPU threads simulatneaously
• when I read; 25% on a i7-quad (8 thread) CPU - single threaded really should do 12.5%
• when I've got a high end cooled system and temperature management reports a jump from 50 to 63 (*C) on all cores simultaneously
• when I see the Thread Counter jump from 1535 to 1545 on my 12-thread system

then I'm not inclined to conclude that the process is singlethreading.

in my opinion,

• when caching the IDL pass (see figure) with the metering included,

then I'm not inclined to conclude that the process is single threading

in my opinion,

• before disputing my abilities to measure, analyse and conclude

• and lecture me about things (which feels quite offensive BTW)

• just ask for the data to re-analyse yourself

• just supply verifyable measurements on your own

• just supply a decent reference when claiming that single thread processes on a 8-thread CPU can cause 25% load in taskmanager

in my opinion, whenever I can go wrong, I will. I don't mind to be told so, on the contrary. But at least show the decency to do so on a facts basis. Especially when I showed the willingness to give some support to my fellow Poser users and ran some tests etcetera.

Very sorry aRtBee... I wasn't meaning to come across like I was being dismissive of your advice... in case I was?? Many apologies if so...

I see your point re. 25% being more like equivalent to two threads on a quad core (or I guess one core)?

Anyway, as I said, I've realised what I'm seeing definitely only seems to kick in after the scene gets beyond some sort of complexity... what I think ssgbryan had suggested to me back at that Rdna thread I started previously on this was that it could be memory to CPU ratio related.

In that Rdna thread I been talking in terms of Queue Manager... but I guess QM or Poser background process... both are managing Firefly... and its the FFRender process I'm essentially talking about here.

So, what I wasn't making clear at the outset, of raising this point, was that there seems to be this aspect to the issue... of scene complexity...

...as I said, I'd need to investigate more myself to see if I can identify the point (in terms of scene complexity) at which IDL and final passes seem to stop utilising much more than 25%... on my system at least.

So I really shouldn't have probably brought this up in this thread... sorry!

Cheers ;-)

@monkeycloud,

The only time when rendering my CPU Usage drops for a prolonged period, is when memory is close to maxed out.

So I guess what monkeycloud is suggesting for this thread (making it all on topic), is the ability for poser to shrink maps as needed, and more BB procedural shaders, to decrease the memory usage?

Quote - @monkeycloud,

The only time when rendering my CPU Usage drops for a prolonged period, is when memory is close to maxed out.

So I guess what monkeycloud is suggesting for this thread (making it all on topic), is the ability for poser to shrink maps as needed, and more BB procedural shaders, to decrease the memory usage?

He he.... quite possibly. thanks General... yes I'd vote for both those things ;-)

But, that said... the render I'm running at the moment is currently doing the SSS pass.

FFRender is using 785% CPU, 4.45 GB Real Memory and 4.61 GB Virtual Memory (i.e. disk swap space)... active memory is at 8.67 GB total usage on my 16 GB system.

I'll let you know what happens when it hits the Final Render pass ;-)

EDIT: Oh yeah, and I'm reworking the scene currently to use just IDL emitters (along the lines of Seachnasaigh's tips in the thread at this link) instead of any actual spot or point lights. So will see if there's a difference after that...

...as I say, the apparent bottleneck, or whatever it is, only seems to crop up after I've either added over a certain amount of content, or after adding the lights (or perhaps certain lights).

Well... okay, it has hit the final Render pass now.

CPU dropped back down to between 195 to 205%, Real memory at 5.57 GB and Virtual memory at 5.96 GB... but admittedly my total used RAM is now sitting at 15.15 GB... so only 850 odd MB free RAM.

So I guess it is probably CPU to RAM ratio that's causing the CPU usage to back off???

I guess I'll see what happens when I revert to rendering the same amount of scene content, but without any lights per se... just IDL emitters.

;-)

When you run out of RAM, swapping starves the processes, so having more is worse. This is not unique to Poser. If you had fewer threads running, the total RAM needed might drop below your physical amount.

Hmmm... okay. I'll try less threads next time. I had ramped that right up to see if that helped the issue, but it may have aggravated it I guess.

Is there an optimal number of threads to specify, for a quad core i7?

Also, am I best leaving the bucket size at the default 32... or increasing that?

Okay...this may seem OT... but actually I've realised what I'd most like from Poser right now (and from here on in) is to get optimal performance out of the current build... LOL ;-)

The optimal number of threads is 8, unless you are swapping, then it is less than 8.

There's no simple answer. If you can't hold 8 copies of your scene buckets in memory, then 8 is not optimal. If you can, then it is.

The total rendering memory is going to depend on many things. To speak in generalities, the minimum shading rate determines (inversely) how many micropolygons you will be holding in a bucket. The bucket size (squared) determines the dimensional area of the bucket. Total micropolygons in RAM during rendering is proportional to

R = (bucket size) * (bucket size) * (number of threads) / (min shading rate)

So you have 3 things that affect your total RAM, R, generally speaking. And, generally speaking, when

R < your total physical RAM

Then you render much faster than otherwise. When R becomes greater than your total physical RAM, you will thrash and you will experience an enormous reduction in render speed.

There is no magic formula. Perhaps you will get R low enough with:

6 threads and 32 pixel buckets and MSR=.7

or

4 threads and 32 pixel buckets and MSR=.4

or

8 threads and 16 pixel buckets and MSR=.8

Which of those is optimal? I can't say. It depends on whether you really need MSR below .5 or not. If so, then #2 is best. If not, I suspect #3 is best.

Note that I have no idea what the equivalencies are. It may be that .1 MSR is way more of a factor than 1 thread.

But #1 may be a good compromise.

And if you lose a couple lights or props, maybe all of those are stupid.

Cool... thanks BB. That's just the kind of summary / synopsis I was hoping for at this point :-)

I appreciate there's not a magic formula... but at least that gives me a heuristic to work from... and significantly more understanding than I previously had.

I'll try out option #1 there with the current scene and see how that works out, compared to how it was working out... and go from there.

monkeycloud, your numbers don't sound to me like your system is running out of memory. There might be other things preventing all threads from running simultaneously. Did you by any chance turn off texture filtering? Should we take this to a separate thread maybe?

Quote - monkeycloud, your numbers don't sound to me like your system is running out of memory. There might be other things preventing all threads from running simultaneously. Did you by any chance turn off texture filtering? Should we take this to a separate thread maybe?

Hi Stewer

I do have texture filtering set to "none" on some Image map nodes... set to "quality" on others. What are the implications of that?

I think I should probably install SP2.1 in the first instance and then, assuming the issue is still there, I will start a new thread for this...

...I can then follow aRtBee's lead and do some more diagnostics. I'll see if I can chart the process life cycle under OS X somehow.

I'm running a QM render now using BB's suggested option #1 above... I left it running overnight, but having come back to it, it seemed to have reached just over 66% (end of SSS pass?) and was sitting down around 150% CPU. Memory usage about 5 GB real and the same in virtual / swap.

So have left that running for the day...

Anyway... a new thread on this in due course I expect... I can run through a table of render settings, based on BB's suggested heuristic values, more systematically, and take some actual measurements...

Cheers ;-)

One thing, maybe more on topic...

BB, I'm refering to an old post of yours I stumbled across trawling through the Node Cult forum at Rdna... here.

You made a passing mention in that post regarding Firefly's Transparency parameter being a color, not a number... but said this just wasn't exposed via the mat room's advanced nodes UI?

If this still holds true, would it be a good idea for SM to put a little work into exposing an additional UI parameter, so we could set a color for transparency?

Or are there other issues barring that actually working in a useable way perhaps?

Cheers ;-)

Stewer told me about that possiblity, but I don't recall talking about how hard  it would be. Seems plausible.

In fact, because refraction blocks all light, I'd like to see a new parameter not just define transparency as a color, but a separate one for light blocking versus seeing through. Right now, both are tied to the transparency value, and when I want to use refraction, I cannot get light to pass through. I'm not looking for caustics - I just want to make a drinking glass where I can use refraction to see through it, but use transparency to allow light through to reach the table or whatever is under/behind the glass.

I'd also like the IOR of a surface to be inverted when a ray goes from back to front - and it should deal with total internal reflection.

Because of these two problems, I have trouble making glass look completely as it should and also trouble making it cause a reasonable light/shadow pattern on what is around it.

One thing I would like to see changed in future versions is the way lights are handled.

Currently if a Light is selected you can not delete it with the delete key like other objects. Also the delete object button is grayed out if a light is selected. This seems unintuitive to me.

Also you can not parent a light to a prop or anything else. I would like to rotate all of the lights in a scene by rotating a master, or have them follow a figure. That's not the same as "Point At"

Why not have "Light Dots" so you could have a collection of lights right there?

You can parent a light to a prop or figure. Just drag it onto the actor in the hierarchy editor

Quote - I do have texture filtering set to "none" on some Image map nodes... set to "quality" on others. What are the implications of that? 

Disabling texture filtering dramatically reduces the efficiency of the texture cache. When using large textures, this can result in a lot of disk access from the renderer, since it has to load new texture data constantly. Since only one thread at a time can access the disk, render threads can end up spending most of their time waiting until it's their turn to read texture data.

Quote - > Quote - I do have texture filtering set to "none" on some Image map nodes... set to "quality" on others. What are the implications of that? 

Disabling texture filtering dramatically reduces the efficiency of the texture cache. When using large textures, this can result in a lot of disk access from the renderer, since it has to load new texture data constantly. Since only one thread at a time can access the disk at a time, render threads can end up spending most of their time waiting until it's their turn to read texture data.

That's a great piece of information, explains some issues I didn't know I had in the past.

Thanks Stewer. In that case I'll try correcting that aspect before anything else...

Very useful to know! :-)

I remember that bagginsbill has mentioned in the past that poser interface could be changed via python, however noone made such an efford, so since it can be done already I would love poser-interface presets!

Quote - > Quote - I do have texture filtering set to "none" on some Image map nodes... set to "quality" on others. What are the implications of that? 

Disabling texture filtering dramatically reduces the efficiency of the texture cache. When using large textures, this can result in a lot of disk access from the renderer, since it has to load new texture data constantly. Since only one thread at a time can access the disk, render threads can end up spending most of their time waiting until it's their turn to read texture data.

@Stewer

Well I've set the unfiltered image_map textures to be filtered to either "crisp" or "quality"... based on your point about disk access, for texture reference, being a likely source of threading bottlenecking, I've also tried optimising various other textures (e.g. by shrinking the pixel sizes of texture image files for anything not in close up) and that large scene is now rendering much faster, with much higher CPU utilisation.

It's still taking a long time... but its another pretty stupidly complex scene I'm doing I guess. Having those seven environment spheres enclosed within the main environment sphere enveloping the scene, probably won't be helping... LOL.

Especially if texture image referencing from disk is the multi-threading nemesis.

So optimising the maps for those, has helped a lot too by the looks of it... as well as making sure that texture filtering was on everywhere ;-)

Many thanks for all the advice relative to my off topic interjection!

cough...as for what I want from Poser ;).....

I would like better glass, similar to what BB suggested in a thread where the trans could be linked either to refraction or a color. He said he wasn't looking for caustics, but that WOULD be nice, even if I'm certain we'll never get it...lol.

One thing that I think is really important is the ability to stop and resume a render - at least in the pro version. Composite nodes in the material room would also be extremely nice.

Laurie

don't be so pessimistic. I think we'll get caustics one day.  why not?  other render engines can do it.

Love esther

Quote - don't be so pessimistic. I think we'll get caustics one day.  why not?  other render engines can do it.

Love esther

Perhaps with Poser Pro 2036....LOL

Laurie