Has anyone else noticed that the mat room is really laggy?  I make one little change and my cursor become a circle and the preview screen goes gray for a minute.  Is there anything that can be done about it?

And - what SR? What OS (I see 64 vista but let's make sure)? OpenGL or SreeD? If OpenGL, what card and driver?

Otherwise, I have seen nothing like this since early versions.

Yeah, mine has too. I assumed it was cause I was using shaders with so many nodes. It's definitely slower then.

Oh, Nvidia GT240

Laurie

It can get "laggy" if I have a complicated scene: six figures, thirty buildings, twelve cars, that kind of thing.

But then the material room being a bit slow is the least of my problems hahahaha.

SR3. I think I'm using openGL, but I'm in the middle of a render and can't tell.

The scene was vicky, a sword, an outfit, some hair, a tree, and a one sided square.

My card is a geforce 275.  Driver is 9.18.0013.0479 (DLed the one that came out right after GW2 was released).

yup, have noticed some laggyiness in the mat room of PP2012 ( but not in the vanilla or SR1/SR2 versions) from SR2.1 up.

W7 64bit , Athlon 2 Quad, 8Gb DDR3 ram, nvidia GeForce GT 430 ( 1Gb of ram onboard)

This is a way out there suggestion but try hiding the tree. I have a tree or 2 that bog down scenes worse than anything else in my runtime.

Hopefully the video cards mean something to some people. I have a Radeon HD 5770 and it is just fine - I have no idea if it is new/older better/worse than yours.

I would suggest verifying without hardware preview, i.e. SreeD. If editing in the mat room is no longer laggy, then there is some unfortunate interaction with the video driver/hardware.

Now - just to be clear, if I have a material with 8 or more of those noise nodes (fBm, Noise, FractalSum, etc.) then it is laggy as all hell in updating. That's just because the tech to do the preview is probably lame.

All that stuff was developed long ago and bought for Poser 5. I don't think it has had an overhaul, ever.

I will say it again and everybody should repeat - I have 8 CPU arithmetic cores. Any program that only uses 1, like it's 1999, is soon (6 years or less) going to be removed from my computer - period. When I have 64 cores, anything that can't use them will be in the trash.

I already have hundreds of processers in my cheap graphics card, capable of 520 GFLOPS. If, in 6 or so years, I am sporting several thousand processers and can do 8 TFLOPS and the software I use is stuck using about 1/100th of that, it's going in the trash.

I expect real-time material preview, including reflections, in 5 years. SM?

I'm hoping I live long enough to own 1 million CPU cores.

Try doing a cloth or hair simulation. It'll chug along for an hour or so using hardly any CPU or RAM.

Great bit of coding that.

There is little to no value in IBL resolution above 512. Why would you do that? It consumes resources like mad for no benefit.

Are you familiar with the "Diffuse Convolution" algorithm? If not, then I understand why you have no idea that such resolutions are evil.

Paul Debevec is the Godfather of environment mapping techniques, such as IBL.

He wrote:

Quote - It may be good to downsample the environment image first since the convolution calculations can take quite a long time.

The purpose of that parameter is for you to DOWNsample your image, not keep it high res or, shudder, to up sample it.

http://ict.debevec.org/~debevec/HDRShop/tutorial/tutorial6.html

Quote - Resize the image. Click on Image in the menu bar, then Size from the Image menu then Half Size from the Size menu. Repeat this several times until the image has been resized to a point where HDRshop can calculate the convolution in a reasonable amount if time. In this example the image has been resized to 128x64 and the convolution calculation takes about 96 seconds.

Things are faster now, but he was dealing with 96 seconds!!!!

Most of the pros use 128 or 256 pixel IBL.

When you put in an environment like this:

The diffuse convolution of it (what is used as the information for the diffuse IBL lighting calculations) looks like this:

Why do you need a high-res version of that?

Back when I used IBL (I almost never do now - I use IDL and my EnvSphere) for global/ambient light, I often made it 32 pixels and it was great.

I've only been using poser for a short while, so i got no idea what the "Diffuse Convolution" is. But generally, a higher pixel IBL was lagging up the material room for me. Turning it down to 100 got rid of the lag, even at 500 there was noticeable lag. But i'll be sure to keep it lower now that i learned high pixels is useless ;)

Oh, Grr, I so hope they get rid of IBL by PP2025. :-)

Quote - Oh, Grr, I so hope they get rid of IBL by PP2025. :-)

"In the year 2025

If Cupa 's still alive

If Baggins can survive

They may find

In PoserPro 2025..." :lol:

I am using OpenGL. I'll try Sreed.  Are there any pros and cons to using one over the other?

My card

http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-275/specifications

your card

http://www.amd.com/us/products/desktop/graphics/ati-radeon-hd-5000/hd-5770/Pages/ati-radeon-hd-5770-overview.aspx#2

Quote - Paul Debevec is the Godfather of environment mapping techniques, such as IBL.

He wrote:

Quote - It may be good to downsample the environment image first since the convolution calculations can take quite a long time.

The purpose of that parameter is for you to DOWNsample your image, not keep it high res or, shudder, to up sample it.

http://ict.debevec.org/~debevec/HDRShop/tutorial/tutorial6.html

Quote - Resize the image. Click on Image in the menu bar, then Size from the Image menu then Half Size from the Size menu. Repeat this several times until the image has been resized to a point where HDRshop can calculate the convolution in a reasonable amount if time. In this example the image has been resized to 128x64 and the convolution calculation takes about 96 seconds.

Things are faster now, but he was dealing with 96 seconds!!!!

Most of the pros use 128 or 256 pixel IBL.

http://www.hdrlabs.com/picturenaut/plugins.html

"

Diffuse SH
It's a plug-in which calculates diffuse convolution of an HDRI (panoramic format). It speeds-up complexity to O(n) against O(n^2) of the naive algorithm implemented in HDR Shop 1.0.3. The algorithm is based on the paper "An Efficient Representation for Irradiance Environment Maps" by Ravi Ramamoorthi and Pat Hanrahan of Siggraph 2001. In the example the computational time is less than a second with an 512x256 HDRI, against the six hours expected using the naive algorithm. This plugin creates a ASCII file with the coefficients of Spherical Harmonics calculated"

http://www.cs.berkeley.edu/~ravir/papers/envmap/envmap.pdf

Quote - I'm hoping I live long enough to own 1 million CPU cores.

He he. Sounds good.

I'm hoping I live long enough to be running an infinite non-number of quantum computing cores...  or however these end up being structured

If I don't live long enough, maybe I can ask in my will for my grandchildren to send me one back in time...

Quote - Try doing a cloth or hair simulation. It'll chug along for an hour or so using hardly any CPU or RAM.

Great bit of coding that.

I'm guessing these are still single-threaded processes, at present?

Quote - > Quote - Oh, Grr, I so hope they get rid of IBL by PP2025. :-)

 

"In the year 2025

If Cupa 's still alive

If Baggins can survive

They may find

In PoserPro 2025..." :lol:

ROFLMAO!

Quote - > Quote - Oh, Grr, I so hope they get rid of IBL by PP2025. :-)

 

"In the year 2025

If Cupa 's still alive

If Baggins can survive

They may find

In PoserPro 2025...

Poser figures, now alive

bending like the real thing

every Poser users dream...

Please everyone, continue...lol. You know ya wanna...

Laurie

Okay, new PC same problem in both sreed and open GL.  Windows 7 64 bit, i7 core, 16 gigs ram, 660 Ti gfx card latest drivers, I need to update to SR3.1 but I see nothing in the change log mentioning mat room preformance.

So aside from the SR update, I'm going to assume one of two things:

1.  It's a preference setting I can correct

2.  The mat room is bugged and I can't correct it.

So are there any settings I can tweak which can speed up mat room interactions?

Are you still getting a minute delay in screen updating?

Is there anything specific in the material room which we can try? (nodes or some kind of user action which shows it?)

If I do a copy/paste of a bb material setting (63 nodes) it takes less than a second.  Changing parameters in this setup takes less than a second as well

Or are your scenes very complex?

I had this issue for most of the day yesterday where it was ridiculously laggy between updates. I would literally tweak a setting and watch youtube videos on another machine while waiting for the refresh to be done. I saw that I had some textures using absolute paths so I had to redo them and when I started over it was much better, but it's still laggier than I like  (about 1-2 seconds) considering I'm running a 6-core processor @3.4ghz, Nvidia 580 gtx 3gb, and 32GB of RAM.

Only item in the scene is one character that I'm doing materials on.

Quote - I'm hoping I live long enough to own 1 million CPU cores.

I never dreamed as a child I'd someday casually carry 5 color displays (phone, ipod, 3DS) simultaneously in my pockets.

Quote - Or are your scenes very complex?

 No, even with a few nodes this problem pops up.  As for specifics, it's most noticable with the dials on the nodes you can add (like math node).  But maybe I'm noticing those because I'm using them a lot.