I recently upgraded my render rig and as part of the upgrade I bought an SSD to hold the windows swapfile and the Poser temp files with the intent of speeding Poser up.

I went into my windows user temp settings [C:Users"username"AppDataLocalTemp] and copied the "Poser Pro" folder and sub-folders over to the SSD swap drive then changed the Poser preferences to point to the copy of the temp folder... I saved the preferences as the new default then closed and restarted Poser.

Sure enough Poser seemed to start faster but when I went to render it was sill slow. So I opened the Windows 7 resource monitor to discover that Poser was writng an exr file to the old temp location on my Primary OS drive under my temp folder...

Is this behavior a hard coded  "undocumented feature"? Is there a way of changing the exr file path? I've checked the registry and most of the XML and ini files and can't seem to find where the path is located.

Any help is appreciated!

Render Rig:

Poser Pro 2012 -SR3.1

Dell T7500 Dual Xeon Quad Core E5520

24 Gb ECC RAM

272 Gb RAID 0 OS Drive

1,800 Gb Application Drive -- Poser Pro Installed here

1,000 Gb Data Drive

80 Gb Swap drive with 36 Gb for windows swap

Nvidia Quttro FX3800

Yes... I do computers for a living.

Many programs are coded that way, it's not a bug... The path is part of the op system based on user name. But there are many ways of getting aroung it.

Read this...HardLinks are your friend, and have been around for a while

http://www.starkeith.net/coredump/2009/05/18/how-to-move-your-windows-user-profile-to-another-drive/

That is incorrect assumption.

A program which does not do what it was designed to do has a bug... The .EXR file that is being accessed is the actual render that Poser is building... it -- by definition -- is a temporary file.

This should have nothing to do with the local profile other than by default PoserPro uses the "User Profile:AppData:Roaming: PoserPro" folder to store temp files by default.

When I changed my default runtime to a different location than the default  profile location, it moves -- so I have a folder called Runtimes which has multiple runtimes... I should be able to move the temp file location without moving my profile but it does not -- which makes this a bug rather than a feature...

In Windows when I move the swap file to a specific drive-- it moves... per the Poser documentation when I move the temp file it should move as well... but apparently FFRender64  does not do this and instead uses a hard coded environmental variable rather than reading the XML configuration or the poser.ini file . The hard code forces the file to be written to the OS user profile location rather than the "temp file" location as set in Poser. This defeats the purpose of  setting a "temp file" location.

I've tried rendering both with a "single thread" and a "separate thread" neither make a change... . Since disk read and write time are important for fast renders PoserPro renders much slower than it has to because I can't put those temp files on the SSD..

When app programmers take lazy short cuts [and this was a lazy short cut!] and don't think their design through you end up with sorry code and angry users who have to make "Rube Goldberg" solutions to correct the lazy programmers. Moving the user profile is a Goldberg solution but that looks like what I will have to do.

By the way a post at Microsoft in answer to the question about moving the user profiles  says:

"This setting should be used only in a test environment. By changing the default location of the user profile directories or program data folders to a volume other than the System volume, you will not be able to service your Windows installation. Any updates, fixes, or service packs will fail to be applied to the installation. Microsoft does not recommend that you change the location of the user profile directories or program data folders...."

Is your hard drive light constantly on during a Poser render?  If not, then using an SSD will not increase render speed anyway.  You should report the hard-coded tempfile that Poser creates though.

Attached Link: http://superuser.com/questions/150012/what-is-the-difference-between-local-and-roaming-folders

Assuming you have a roaming user profile and several machines on which you can log in with that account and use Poser. There are certain files that you'll want to have in the roaming profile: the preferred scene, preferences, UI layout, recent renders. Other files you want to keep local and not roaming: the render texture cache, temp files for undo, shadow maps or temp files for dynamics calculations.

 That is why FireFly writes the result of a render to the roaming folder: it is not disposable temporary data, it is valuable user generated data that you would not want to have thrown away by a disk cleanup tool.

 In either case, the overhead from writing that file is negligable compared to what else is going on during a render and very unlikely to be a limiting factor for your render speed.

when an SSD is capable of 150 Mb/s of data transfer and a typical two drive Raid 0 and only do about 30 Mb/s of data transfer and the temp file .exr is the target of the render dont you think moving that file to a faster drive will lead to faster render?SSD are almost as fast as writing to memory

My last system was a Single Q9550 Quad Core with 8 gb of RAM ... An IDL scene took a while to do... the new set-up is over twice as fast but the limiting factor seems to be the file that poser is writing that render file during the render... I'm not bothered by a long load time for a scene file but the faster the render is written the faster the render gets done.

Btw I've discovered that the Queue manager does the same thing.here's the commandline as it appears in Queue manager:

 E:applicationsSmith MicroPoser Pro 2012FFRender64.exe 4415 C:UsersUSERNAMEAppDataLocalTempQueue Manager92013- 4-29_ 3h 0m18s 1 indirectLightPrepass.xml C:UsersUSERNAMEAppDataLocalTempQueue Manager9quRender 1 1.exr C:UsersUSERNAMEAppDataLocalTempQueue Manager9

Apparently a Tempfile setting made in PoserPro are effectively meaningless.

If I had the cash to put out for an array of SSDs I would but a four drive array would set me back quite a bit of cash.

Quote - when an SSD is capable of 150 Mb/s of data transfer and a typical two drive Raid 0 and only do about 30 Mb/s of data transfer and the temp file .exr is the target of the render dont you think moving that file to a faster drive will lead to faster render?SSD are almost as fast as writing to memory

How large is the temp exr file that's being created? Depending on the resolution, they just a couple dozen MB in size or even less, so in most cases that would take 3 seconds or less even on a laptop hard drive (my laptop's hard drive measure about 20MB/s).  

Quote - My last system was a Single Q9550 Quad Core with 8 gb of RAM ... An IDL scene took a while to do... the new set-up is over twice as fast but the limiting factor seems to be the file that poser is writing that render file during the render...

What makes you so sure that writing the file is the limiting factor? How large is that file?  

Quote - when an SSD is capable of 150 Mb/s of data transfer and a typical two drive Raid 0 and only do about 30 Mb/s of data transfer and the temp file .exr is the target of the render dont you think moving that file to a faster drive will lead to faster render?SSD are almost as fast as writing to memory

That's all fine and dandy if the hard drive is always on while you are rendering.  My CPU is not waiting for any drive I/O while it renders.  A better fix would be to add more RAM so that the hard drive light rarely comes on if your CPU is waiting for data a lot.

Well to answer both questions:

I have 24 Gb of memory... Poser rarely uses more than 8.5 Gb when the bucketsize is set to 64.... I'm trying a larger bucket size now and using the queue manager so their is less over head with screen refresh

The exr.files vary from 14 to 20 mb -- exr is a hdr type [I read somewhere it originated with Pixar Renderman] but as the render progress it apparently is writing and re-writing this file... the exr is what is displayed in your 'saved renders'

As to roaming verses local profiles and temp folder. -- In reality they should have nothing to do with one another... unfortunately it seems that the programmers at SM fail to see it that way... and so the temp folder setting is nothing but something left over from pre-Vista times...it actually might work on XP but I'm running Win7 x64 SP1

Look at it this way -- the temp folder does NOT need to be attached to the windows profile. there is nothing in there that is either harmful to 'userspace' nor is it likely to be used for subversion of security.... much like the runtime... I've never put the runtim in my user space because It makes it hard to move when I upgrade... so runtimes are never on primary OS drives... and frankly I don't see whay the tempfiles are any different... oh yse the saved renders are in there and yes for some reason

I've administered Windows networks and workstations since 1996.. and know a little about it [maybe not enough being a general specialist ;)]... this looks to be an "undocumented feature" that is weighed down by the MS idea that application data should be attached to user profiles when 'temporary files' are application resources not user resources.

Well.  There's temp files.  And then there are temp files.  Two totally different things.  So you can't strictly go by what they are called.

Twice now you've mentioned how long you've been doing computers for.  Makes no difference, since you need us to help you.

I'm a bit lost here, but perhaps my own findings can be of help.

1. I never ever put temp files on my SSD. SSD's are great for write once read many files, like Program Files and (not too huge) Content Libaries.

2. with 24Gb ram inside I created a dynamic / 4Gb RAM disk (B:) for temps. You can't beat ram drives fo speed, and they (usually) start clean at bootup. In Windows I redirected my TMP and TEMP system variables to my B: drive.

3. Poser temp file folder is set in General Preferences, Misc tab.

4. Poser render results are not cached in temp, but managed separately. The amount of seved results is set in General Prefs, Render tab.

For your convenience: I put a tutorial on my website http://www.book.artbeeweb.nl/?p=162 describing how to handle Poser as a program, addressing CPU, RAM and similar issues. You're welcome.

Quote - The exr.files vary from 14 to 20 mb -- exr is a hdr type [I read somewhere it originated with Pixar Renderman] but as the render progress it apparently is writing and re-writing this file... the exr is what is displayed in your 'saved renders'

It's written bucket by bucket, as they come in from the renderer. At an average hard drive (non-SSD), the overhead from writing a 20MB file should be second or two in the worst case (the Seagate Barracuda in my desktop does up to 140MB/s write speed).

Quote - I've administered Windows networks and workstations since 1996.. and know a little about it [maybe not enough being a general specialist ;)]... this looks to be an "undocumented feature" that is weighed down by the MS idea that application data should be attached to user profiles when 'temporary files' are application resources not user resources.

We may agree or disagree with Microsoft's decisions as much as we want, at the end of the day, software that runs on Windows has to play by Windows' rules or it risks breaking with OS updates. In my experience, when you try to fight the OS, the OS almost always wins.

@aRtBee

1. then you are missing the point of SSDs... they are intended to be used anywhere where fast Read/write is helpful... just because they can't be  swap files are an example... or files which require high speed  I/O... mySSD can write at least 5 times faster than my RAID"0" C drive.... whci is why I use it for my windows swap... and why I'd like to use it for other things... but it does not seem to be much help for Poser.

2. RAM disks are fine and well as long as the computer stays powered on... lose power you lose your temp files... which under certain circumstances may be "a bad thing" for example using memory for a swap disk is  probably not a good thing... nor for storage for things you have not saved to permenant storage... nor files which are used to stop, start or cache information used by Windows or your applications.

3. Yes and the point of the temp folder is? Looking at the actual files [which includes the rendered image cache] tells me theres nothing there that could not be put on a different drive than the %user appdata%

4. Yes the renders are cached in the same location [maybe you have not tried what I have done]. I moved the whole poserpro app data temp file cache to a different location. Apparently FFRender64 is hard coded to use :AppData:Roaming:PoserPro:9:RenderCache: to store the image as it is being rendered... upon completion of the render the file is copied to the temp file location... in my case this means that the files is rendered onto my C drive then at the completion of the render it is copied to the RenderCache on my D: drive... which sort of makes the whole idea of being able to move the temp folder' moot

I'll be glad to take a look at your tutorial... but seems to me I'm barking up the wrong tree as apparently moving the temp files achieves no useful purpose... so much so that one wonders why the feature still exists... especially since the programmers hard coded where the images will be rendered.

Quote - We may agree or disagree with Microsoft's decisions as much as we want, at the end of the day, software that runs on Windows has to play by Windows' rules or it risks breaking with OS updates. In my experience, when you try to fight the OS, the OS almost always wins.

Ain't that the truth! Unless you run it on Linux... ;) Yet is just seems to be totally bass-ackwards for a rendering app to be at the mercy of a user's profile... if the profile gets corrupted you lose all your work... and mixing appdata with user space data is less than optimal.

In any case I'm giving up on what apparently is a quixotic adventure...

thanks for the comments...

Quote - @aRtBee

 

1. then you are missing the point of SSDs... they are intended to be used anywhere where fast Read/write is helpful... just because they can't be  swap files are an example... or files which require high speed  I/O... mySSD can write at least 5 times faster than my RAID"0" C drive.... whci is why I use it for my windows swap... and why I'd like to use it for other things... but it does not seem to be much help for Poser.

Of course, unlike dynamic RAM, the lifetime of an SSD is governed by the finite number of writes possible before memory location fails; I believe they are rated at about 3000 writes.  Since I have a bit more time than cash, I'd keep temp files off of an SSD, but your priorities may be different; if time were indeed more important to me than cash, I'd keep a spare SSD....

In Unix land the way I would resolve this is move the RenderCache directory to somewhere on the SSD and create a softlink in the orginal parent directory called RenderCache. The app will still think the RenderCache is still in its old location when in fact its on the SSD.

Windows has a similar junction/softlink system. I've never had to use it so can't give you any practical advice but if your interested checkout articles on MKLINK and Sysinternal's junction. 

If you’re using Poser’s Queue Manager, check if there’s an option to delete temporary files after rendering. This setting might influence where temporary render files are stored. Sometimes, other users may have encountered and solved the same issue. Checking forums dedicated to Poser, such as Renderosity, might provide insights or solutions shared by the community. Ensure that Poser and all related software are up to date. Sometimes, updates can fix bugs or undocumented features that cause issues like the one you’re experiencing. If none of the above solutions work, consider reaching out to Poser’s customer support. They might have internal documentation or patches that can help resolve the issue.

gishzida posted at 10:22 PM Sun, 28 April 2013 - #4062882

By the way a post at Microsoft in answer to the question about moving the user profiles  says:

"This setting should be used only in a test environment. By changing the default location of the user profile directories or program data folders to a volume other than the System volume, you will not be able to service your Windows installation. Any updates, fixes, or service packs will fail to be applied to the installation. Microsoft does not recommend that you change the location of the user profile directories or program data folders...."

If you use symbolic links, the operating system has no clue you ever moved anything... It is completely transparent, unless it fails and the link is no longer active at the other end....... Those are pluses and minuses to symbolic links......

My user directory and program information is on a the P: drive, and I has been since I installed Windows 10. I am now on current Windows 11, all thru updates, and 2 motherboards later with no reinstalls of Windows since Windows 10 64 bit was installed on a cheap I3 system........ You can also do scripted installs on Windows where none of the user or program info is on the boot drive, and it updates fine...... My install of Windows 10 was done thru a scripted install, that I wrote myself.... I learned how to do that, when I got my MS certifications, from Microsoft........ 

Writing to SSD's is not always fast, that is a myth for people that will actually believe it... Assuming that they are always fast, is not a very good idea, because they are not always fast for obvious reasons. I have a lot of ssd's on my system, 5 in total, with 11 terabytes of total ssd space. One of them is under two gpus, guess how fast it is in that environment???? It is presently at 61c, idle, and it is never fast for that very reason..... I am presently building a AI model, which is why it is so warm........ It is just use that SSD as a scratch drive, so it doesn't really matter if it is slow.....

Small writes to any SSD can be as slow as 40 meg a second, depending on the drive, the bus it is on, lane sharing latency issues, size of info writing to it, firmware, drive cache size location, free row count, temperature (which has huge effects), motherboard chipset, bifurcation support, etc, etc, etc..... Sure 2 of my SSD's spec out and Crystal Mark out at 7gig read and 4 gig write, and one actually exceeds that, but only in the top categories and only when it always get 4 lanes without waiting for them outside of a benchmark that takes that into account... Having available lanes is not always the case thou, because there are only so many Pcie lanes to go around........ My CPU has 20 pcie lanes... How many do you think two gpus, 5 ssd's, multiple hard drives, usb, etc, adds up too? My gpus are even running on 8x8x shared lanes versus 16x if I only had one gpu..... Yes, the lanes have to be shared, and my system is running in 8x4x4x4x mode..... Which means that ssd's may indeed have to wait for available lanes, because there are only 8 left for all the drives, usb, etc, etc, etc................. All systems work this way, there are only so many Pcie lanes to go around, and they can only be split up certain ways...... Fast drives, will never always be fast when they are waiting on lanes to free up...... Just because you have a 16x gpu, doesn't mean it is running at 16x, and just because your ssd has 4 lanes, doesn't mean it always get 4 lanes that are always available..... Obviously if you have an Epyc server system, you wont have to wait on Pcie lane sharing, Epyc cpus are set up differently, and don't have a limited number of Pcie lanes for IO..... They do have other latency issues with them thou, that can slow them down as well.....

Feel free to tell me that my assumptions are incorrect......... I worked for Microsoft for a bit, NT and 95 days. I have been doing this since the early 80's.... All of this is well documented, and well known to anyone that knows anything about it, contrary to what you stated. I suggest you find a Windows 95 Resource Manual (Professional Edition), and actually read it. It is just shy of 1000 pages of information people like to state isn't documented.... 

24 gig of memory and Poser, is not a lot of memory.... Poser routinely uses well over 50 gig on my system. I have 128 gig. 26 gig is committed right after boot, which is 2 gig more committed on boot, than what you have total............. I can't imagine why your system is slow...... I am afraid to guess how many threads and handles you have running after boot as well........

One of them is under two gpus, guess how fast it is in that environment???? It is presently at 61c, idle, and it is never fast for that very reason..... I am presently building a AI model, which is why it is so warm........ It is just use that SSD as a scratch drive, so it doesn't really matter if it is slow.....

It's the same in my tower, in which the SSD under the GPU keeps all my Poser executables and runtimes.
But in my case, the crew that design the tower had the great idea to put three 12" fans pulling fresh air in the tower, plus three on top behind the liquid intercooler, so that the air flows through the box with a certain consistency.
Result: the lower SSD is below 30°C (86°F) most of the time, while the one above the GPU (Windows drive) is commonly between 43°C and 50°C (110°F to 122°F)

That being said: thank you for the info about the SSD: both render and movie cache folder were effectively pointing to a fast SATA drive, but bot Poser's temp folder. Setting changed.