As described by RedPhantom a procedural material like grid rather than a texture map would be easier to manage in this case. IIRC procedural mats can still be impacted by the UV layout but a simple cube should be ok. For more complex shapes and UV layouts using triplaner projection would allow a grid to be projected on to the model that would compensate for uneven UV layout but somekind of texture app would be required to do the projection.

Practical example - there is a limited scope to increase detail on breast plate due to UV layout. I could increase to an 8K but the increase in render detail would not be worth the increase in RAM required to render.  lf your own the model then using UV mapper or blender to make full use of UV space is an option. 

Just to explain my post - increasing texture size will increase the amount of detail but when working with older models where PC memory resource was more of an issue the UV map may be stretched to allow all objs in the model to fit on the same texture map. This could lead to less than expected improvements. Attempt at demo of how UV mapping impacts detail below - both images rendered using same obj and image but one of right has a stretched UV map - where the UV grid is narrow the render engine stretches the pixels across a wider section of the obj causing a loss of detail. Stretched UV map shown below also. It should be possible to exploit this to increase detail on parts of the obj where detail is at the expense of areas that are unseen.

I believe Poser projects the image onto to the UV map not the obj, the  effective texture resolution applied to the obj is dependant on how the UV space is mapped to the obj (think this is called  texel density). For example if the tee shirt maps the full 0-1 UV space then increasing the texture size to 4K should increase the texture on the tee-shirt obj to 4K also. If the tee-shirt is mapped to 0.1 x 0.1 UV space the actual texture resolution on the tee-shirt will be much less (sorry bad at math). If using Firefly there is an additional setting (IIRC "min shading rate") that will also determine the effective texture resolution as this is used to "dice up" the model before rendering. 

My imagination greatly exceeds my intelligence so there is probably some major flaw in the logic but the idea is when doing close to medium renders much of a standard image map is wasted. First step is to build a plane mesh were the camera view intersects the ground plane and then stretch the UV to maximise the texture density nearest the camera. Final step is to use triplaner projection to generate the image file. No one has time or patience to do that for each render so the thought was to see if it could be done via a python script, I seem to remember someone had a ground plane generator script. I kind of lost interest at the point.

The reason was going down this route is because I couldn't figure out how to do the texture bombing in Poser, but could in Substance. With your post I think it makes more sense to do it Poser.

Below is my attempt at a manually created POC, but gives a better idea of what I'm trying to achive. On the right is the plane, on left if the UV map and below is the result of the triplaner projection.

Not sure if of interest and not a general solution but trying to solve the same issue , one thought as an alternative to texture bombing is to vary the texel density by distance, don't know if there is a programatical way to do this  but if so could the UV stretch and projection be auto generated by a poser python script on a ground plane. Example render is not Poser but uses UV stretching via substance designer to project onto a static stretched UV.

Thanks for the advice hborre and ghostships much appreciated, it is always fascinating trying to model how light works :) 

Yes so materials are based on the physical properties of the object so it can work with any light set-up. After many years of working on that I've  not had much success so have moved onto pre baking the light into the textures. So I seperate materials as  physically accurate and textures as pre baked. Hope that makes sense. I'm not trying define the terms just interested what peoples thoughts are.

Just to say I think its an interesting question how to represent the quality of "ivory" in either a texture or material way. Both have their challenges. I spend many hours trying to represent ivory as a texture but also how would it be done as a material, I think it is an interesting point of discussion - ie textures vs materials.

Superfly PBR + HDRI

Always liked the way Poser (nod to Carrara ) split up tasks into rooms and I've borrowed this approach to help a small team through a large scale migration. Could Poser 13 be an opportuntity to revisit this area and introduce workflow improvements. My pet favourite is building PBR mats but there must be other places where  breaking down a complex or long task into smaller sections would help. Not a CG pro so probably talking b/s as usual ;)

Excellent idea, just include/drop the install file in the same directory as the python scripts and run

I always think that automation/install scripts follow a 10/90 rule where 10% of effort achives 90% of the functionality but the remaining 10% takes 90% of the time.

These are the thoughts I try to follow when automating a process like an install

 1. Don't modify/delete a users existing files without their consent

 2. Don't trash either the application or other peoples scripts

 3. Use atomic operations where possible so its easy to revert if the script fails

 4. Don't mess up the users hard drive with unnecessary files

Sure there are others, helps to be paraniod :)

Point 1 - Display files to be changed and use set /p to seek confirmation

Point 2 - More difficult, use unique file nameing conventions so less likely to overwite another persons files

Point 3 - Rename function is very powerful when building complex installs - generate new files in temp area and if all works ok at the end just rename file/directory. This is important if the program is running and may lock a file, easier a rename a directory than wind back many ops incase of a failure

Point 4  - Need to consider if version specific and also if user runs the script if no install exists

Just from a discussion point of view, Immediate thought on script is what what happens if more than one version of Poser install

For version specific installs the reg command might help (might be possibe to refine reg command line other otherwises a "for" + "findstr" might do the trick

To find current active version of Poser the "ftype" command, again I wondering if the for command can be used to pull this into an environ var

A minor gripe but pity the manual was removed from the help menu, I keep meaning to finish off various projects, start P11 and its there, start P12 and then its a case of ferreting  through the numerous web links to get to the information at which point I've lost interest. An API is an asset to an application so why hide it. 

An honour to be included with such fine work, thanks Poser team.

hborre posted at 9:26 AM Tue, 29 March 2022 - #4436540

A wonderful render, a nice touch with the soft lighting.  The only thing that bothers me is the extremely dilated pupils for this lighting condition.  Otherwise, the color palette is spot on.

much appreciated Y-Phil