PDA

View Full Version : Pixels per polygon flat-out doesn't work? Or am I doing something wrong



stib
12-14-2017, 09:46 PM
Testing out JSPlacement for making nurnies, and trying the pixels-per-polygon setting in geometry. So if my camera is 1000×1000 and my subdivided plane fits the camera view, when I set the subdivision to 1 pixels per polygon there should be exactly, or close enough to exactly 1,000,000 polygons, right. Nope, I get 20,000, and my model looks like it's made out of chewing gum.

138867

To get the level of detail that I need I have to set it to per object level and wind it up until it's sufficient (at 8 subdivisions I get slightly > 1 pix/poly)

138868

So is this yet another reason to keep learning Blender, or am I doing something wrong?

MonroePoteet
12-14-2017, 11:56 PM
I'm no expert, but isn't it "Pixels per Polygon", not "Polygons per Pixel"? If your camera resolution is 1000x1000, you're getting 1,000,000 pixels output. Reading the documentation on "Pixels per Polygon", I'd guess your model has 20,000 (unsubpatched) polygons in it and setting "pixels per polygon" to 1 constrains the number of pixels to the number of polygons (20,000), which are then stretched across the 1,000,000 camera pixels to look like "chewing gum". Setting the subpatch level to Per Object and bumping it up allows subpatching to create enough intervening polygons to give you the detail you want. Maybe?

mTp

stib
12-15-2017, 12:17 AM
You're right, you are no expert. The pixels per polygon does not affect the render resolution. It's supposed to change how many polygons the mesh is subdivided into at render time. A 1:1 ratio of pixels:polygons should result in 1,000,000 polygons for a 1000×1000 image.

But either way, whether I turn the number up (see image for what happens if I dial it up to 1024) or down, it's still chewing gum.

138871

jboudreau
12-15-2017, 12:31 AM
Testing out JSPlacement for making nurnies, and trying the pixels-per-polygon setting in geometry. So if my camera is 1000×1000 and my subdivided plane fits the camera view, when I set the subdivision to 1 pixels per polygon there should be exactly, or close enough to exactly 1,000,000 polygons, right. Nope, I get 20,000, and my model looks like it's made out of chewing gum.

138867

To get the level of detail that I need I have to set it to per object level and wind it up until it's sufficient (at 8 subdivisions I get slightly > 1 pix/poly)

138868

So is this yet another reason to keep learning Blender, or am I doing something wrong?

I would say something got messed up,

When I have a plane made up of 10,000 polygons

When I put in a subdivision of 0 for instance I get 10,000 polygons, (10,000 x 1 = 10,000)

When I put in a subdivision of 1 I get 20,000 polygons. (10,000 x 2 = 20,000 )

When I put in a subdivision of 2 I get 80,000 (Multiply the sub divsion by itself then multiply by 20,000 (2 x 2 = 4) (4 x 20,000=80,000)

When I put in a subdivision of 3 I get 180,000 (Multiply 3 x 3 = 9) (9 x 20,000 = 180,000 polygons)


When you have a sub division of 3 you should have 180,000 polygons not 20,000 which is a sub division of 1

In your example having a sub divsion of 3 with 8 pixels per polygon should still only give you a polygon count of 180,000 not 1280000


To get a polygon count of 1280000 you would need a sub division of 8 (8 x 8 = 64 64 x 20,000 = 1,280,000 polygons

Here are my Screens

138875138872138873138874

So as you can see from my screen grabs I have the same polygon count for the plane (10,000 polygons before subpatch) but my subdiv polygon count is different from yours. I know mine is correct because the math works, so so something is messed up on your end. What version of Lighwave are you using?

Here is what it says in the manual: Pixels Per Polygon: Ties the amount of pixels of the output frame to the subdivision level of the
cage polygons. For example, a setting of 4 means that a given polygon will have an area no larger than 4 pixels.

MonroePoteet
12-15-2017, 12:50 AM
Here's an old thread that's interesting:

http://forums.newtek.com/showthread.php?102430-Issues-with-quot-Pixels-per-Polygon-quot-render-SubDiv

It says the number of produced polygons is smaller the farther the subpatched object is from the camera. If your object is quite large and the camera is far away, perhaps that's what is limiting the produced polygons. Dunno.

mTp

jboudreau
12-15-2017, 01:18 AM
Testing out JSPlacement for making nurnies, and trying the pixels-per-polygon setting in geometry. So if my camera is 1000×1000 and my subdivided plane fits the camera view, when I set the subdivision to 1 pixels per polygon there should be exactly, or close enough to exactly 1,000,000 polygons, right. Nope, I get 20,000, and my model looks like it's made out of chewing gum.

138867

To get the level of detail that I need I have to set it to per object level and wind it up until it's sufficient (at 8 subdivisions I get slightly > 1 pix/poly)

138868

So is this yet another reason to keep learning Blender, or am I doing something wrong?

I know what your problem is. You are thinking that 1.0 represents 1 pixel per polygon when in fact it doesn't mean that at all. It's confusing because when you put a 1 in that box what you are actually saying is you want it to render with a sub division of 1

See Lightwave has a visible sub patch level where you can see in your viewport and a render sub-patch level where you can only see the results once you render. This is used to help you navigate really dense mesh scenes. So you can have a visible sup patch level of say 2 which will put 80,000 polygons in the viewport. and you can set a render subpatch of 3 which will set your object to 1,280,000 polygons when you render. This way you don't have to have 1,280,000 polygons in your viewport to navigate which would be a lot slower and not as manageable.

Hope this makes sense.

jboudreau
12-15-2017, 01:47 AM
[QUOTE=stib;1527502]Testing out JSPlacement for making nurnies, and trying the pixels-per-polygon setting in geometry. So if my camera is 1000×1000 and my subdivided plane fits the camera view, when I set the subdivision to 1 pixels per polygon there should be exactly, or close enough to exactly 1,000,000 polygons, right. Nope, I get 20,000, and my model looks like it's made out of chewing gum.

Hi I got it working and know what the problem is, If you can't get it working just send me your scene and I can get yours working too, It all depends on the distance from the camera how many polygons you will end up with but also make sure your sub division order is set to last from what I can tell from your images you have it set to First and this is where your problem is. Set it to last and this should fix your issue.

Subpatch Object

138876

Catmul-Clark Subpatch Object

138877

Also make sure your sub division order is set to last, If not you will get this (20,000 polygons as shown below) and it will look like chewing gum like you said

138878

Thanks,
Jason

stib
12-17-2017, 08:16 PM
I know what your problem is. You are thinking that 1.0 represents 1 pixel per polygon when in fact it doesn't mean that at all. It's confusing because when you put a 1 in that box what you are actually saying is you want it to render with a sub division of 1
Hope this makes sense.

Obviously this has been broken for long enough that no-one who still uses Lightwave actually remembers what it's actually supposed to do. Here, if you care to RTFM is how it is supposed to work:

Additional Settings for Render Subpatch Level
Per Object: The classic method of having the same subdivision level for the entire mesh .
Per Polygon: Sets the Subdivision level per Cage Mesh polygon independently (commonly refered
to as variable subdivision)
Pixels Per Polygon: Ties the amount of pixels of the output frame to the subdivision level of the
cage polygons . For example, a setting of 4 means that a given polygon will have an area no larger
than 4 pixels .

…thus, a setting of 1 should mean that a given polygon will have an area no larger than 1 pixel.

EDIT
I started a new scene with some tests, just to check, and whaddya know, this time it's working. It might be a distance from the camera thing, or a scale thing, I'll have to compare the two scenes to see what the diffference is.

BTW you do need to set subpatching first, otherwise it does the displacement on the un-subdivided (i.e. low res) mesh, and it doesn't have the resolution to deform to match the high resolution image. So all the sharp edges and corners get rounded off to chewing gum. Thanks for all your attempts to help, I'm sure you mean well, but explaining stuff you don't actually understand yourself isn't really that useful.

SubD first:

138890

Same settings, bud SubD last:

138891

jboudreau
12-17-2017, 08:21 PM
No, sorry, you're mistaking the manual subdivision setting with the pixels per polygon automatic subpatching. When this was released it was touted as a way of making sure that you always had an appropriate level of detail, by subpatching each pixel enough depending on how big it was on screen. So if you set pixels per polygon to 1 it is supposed to subdivide it enough to give you 1 polygon for every pixel.

Obviously this has been broken for long enough that no-one who still uses Lightwave actually remembers what it's actually supposed to do. Here, if you care to RTFM is how it is supposed to work:

Additional Settings for Render Subpatch Level
Per Object: The classic method of having the same subdivision level for the entire mesh .
Per Polygon: Sets the Subdivision level per Cage Mesh polygon independently (commonly refered
to as variable subdivision)
Pixels Per Polygon: Ties the amount of pixels of the output frame to the subdivision level of the
cage polygons . For example, a setting of 4 means that a given polygon will have an area no larger
than 4 pixels .

…or a setting of 1 should mean that a given polygon will have an area no larger than 1 pixel.

Please don't post to this thread if you don't understand what you're talking about.

Well it's funny if I don't know what I'm talking about like you say. Why was I able to get my mesh not to look like chewing gum and it reported 1,280,000 polygons compared to your 20,000. It has to do with setting the sub division order to last. Try and and then tell me if I don't know what I'm talking about.

Anyway just trying to help you out. I have Over 22 years experience when it comes to lightwave. Maybe you should try accepting the help from other users instead of criticizing the ones that are trying to help you. And if you know so much and don't need the help why both posting in here in the first place. Anyway Good luck with your so called bug.

Thanks,
Jason

stib
12-17-2017, 09:08 PM
It's great that you want to help, but just spraying random thoughts is not helping. Unless you know what you're talking about it's not helping.

You started by telling me that pixels per poly of 1 was the same as setting the subdivision level to one.

when you put a 1 in that box what you are actually saying is you want it to render with a sub division of 1

Every post you've made has been either wrong, or confused.

Like telling me to subdivide last. Sorry. Wrong. See the images in the post above.

You may have use the software for nearly as long as I have, but you obviously aren't familiar with this function.

jboudreau
12-17-2017, 09:23 PM
It's great that you want to help, but just spraying random thoughts is not helping. Unless you know what you're talking about it's not helping.

You started by telling me that pixels per poly of 1 was the same as setting the subdivision level to one.


Every post you've made has been either wrong, or confused.

Like telling me to subdivide last. Sorry. Wrong. See the images in the post above.

You may have use the software for nearly as long as I have, but you obviously aren't familiar with this function.

It's called Trial and error maybe you should try it sometime. It was extremely late that night almost 4am sorry if I made a slight mistake trying to help you. I know what those functions are. If you want me to prove it to you send me your scene and I will take a look and send it back to you with the fixed issue you are having.

Thanks,
Jason