Pro-Lighting: Skies My review

As I am starting to fiddle with the latest version any questions out there on Pro lighting skies before I begin? Feel free to chime in! Here to help.

So upfront because I know it will come up no I do not work for Andrew and yes I paid for the Pro-Lighting: Skies: Review Scores:

Cycles 8/10 - Pro- Fast,easy,effective Con- $$
Add-ons 7/10 - Pro - Simple, great GUI Con - needs some effort to ad your own HRDI
Blender 7/10 Pro - meshes well into cycles Con - not for the game engine

Reviewed: 97 dollar “light option”

Author -Jeffrey Wilson 7/28/2015

Shall we get to it! What the heck is this thing anyways? Well go watch the normal style video of Andrew telling you how the last way he showed you how to something he was wrong! But this time you need to do this new amazing discovery and look at all the amazing insane renders my team made! Sorry Andrew but come on man you know it’s true. The short version is it’s a sky only HRD shared for the world nodes in blender 2.75 cycles render engine.

Pro’s

- It’s just as easy as adding a diffuse shader to a mesh!

- You can work with it in live render!

- It has Andrews support and there mores to come

- Lots of options even at the 97 dollar level

- If your crafty you can add your own HRDI’s

The bad news is I randomly choose one of the cloudy maps and compared it to one of my HRD I have it was only a ram saver on the low setting. So not all the maps are mega savers but I have yet to find one that slows down the live render as much as my normal HRDI maps. It might not be 87% like he claims for all maps but it dose clearly work better without question.

See my screen shots of my sample of one data run. I will run a complete number of tests on all the maps and post my findings.

Con’s

- Its 97 bucks, for those people on a budget it’s a bit of a punch to the face.

- Only improves render times on low level, *dose lower

- 197 dollar option makes you wonder if you are missing out

- It did not come out sooner!

- 85% for only outside scenes.

- Going to make you want the grass pack if you don’t have it already

Got a comment let me know @jeffreywvgd

Now I know someone out there is going to comment and have some input into how this works. Go for it let talk about it and inform the blender world what this is and give them both sides so they have all the info to make up their minds

Links to topics

Pro skies - http://www.blenderguru.com/product/pro-lighting-skies/

Eye ball tort - https://gumroad.com/tomnewbury

Mesh for testing - http://www.blendswap.com/blends/view/4981

Attachments




So…Where is the review?

Andrew needs to compress the image maps with .dds dxt3 or dxt5 and not jpeg because jpeg will decompress to a file size which is the result of the actual image resolution and bit-depth in VRAM and .dds wont.
(.dds is one of the few and the only format that blender supports that can do this.)
Plus the visual difference in the lossy compression between the two is not all that much, .dds tends to look a bit better. He’ll need to disable mipmaps for a smaller file size.

This will actually decrease VRAM usage more. At the moment he’s split the HDR into special jpegs and a black and white image from which the light values can be better preserved from. This may take less VRAM than a normal HDR image due to the differences in color information, but he could save a lot more memory if he used .dds, the image might even look a little better.

sorry an error in loading its up now

[QUOTE=jeffreywvgd;2911465]compared it to one of my HRD I have it was only a ram saver on the low setting. So not all the maps are mega savers but I have yet to find one that slows down the live render as much as my normal HRDI maps. It might not be 87% like he claims for all maps but it dose clearly work better without question.

See my screen shots of my sample of one data run. I will run a complete number of tests on all the maps and post my findings.
/QUOTE]

This is because jpeg decompresses to a full size in VRAM based off resolution and bit-depth.
See previous post about the .dds format and why Andrew should use that instead.

Thanks Jeffrey.

In regards to the memory saving, it can produce up to 87%, but as you correctly noted this figure comes from the low setting. But on high settings, I still usually get a reduction of around 60-70% (3.9gb vs 1.2GB).

@John Lancaster
Thanks for the info on the .dds dxt3 or dxt5! It’s honestly the first time I’ve heard of this, but I’ll definitely look into it for the next update. Cheers!

Do you have any evidence of this, or do you just assume that this happens? I can’t find anything about it in the documentation and according to this comment by Brecht, DDS files are uncompressed for rendering.

Hello!

So I’ve bought The Pro Lighting: Skies addon yesterday, and I’ve tried it out on a render I’ve been doing lately. Unfortunately, when I select a sky hdri a bug occurs. Even though I select another sky hdri, the first one remains in the render. Dunno what’s happening, any ideas?

I’ve sent this to Blender Guru’s support but I thought I’d share this here also in case anyone else is suffering from the same.

Regards.

DDS files should not be decompressed - that’s why video games use those textures, to fit more into VRAM. If DDS textures were decompressed, there would be no benefit to them at all. However, maybe those are misused in Cycles.

I’m aware of what DXT compression is for (not all DDS files are compressed, by the way). Blender supports these textures in a generic way (like any other compressed format) and they need to be decompressed for editing, rendering (on the CPU) and compositing. Even when you don’t have the benefit of compression at all times, it’s still convenient to be able to use these files. While it would be reasonable to support DXT compression for GPU renders directly, you can’t just assume that this is happening.

I think Scene City is a better deal at $60. Not only to you get something like Pro Skies, but you also get a terrain generator, and a city generator.

That’s the whole reason people use .dds textures.
.dds textures do decompress if they are not compressed with a dxt format. There are literally over a dozen other lossless/lossy options.

Do you have any evidence of this or do you assume this happens?

Sounds like it’s time to do some testing to me :slight_smile:
I’ll share my findings.

Okay so it’s not just a glorified Sibl loader.

Cool, I was hoping it wasn’t

So I took an HDR image and compressed it into both jpeg and dds and the resulting memory usage in Blender was the same.
So Blender is not taking advantage of the dxt compression. This would be a really nice feature to have though. Especially for game engine users.

I guess for the time being I’ll just stick with 16bit .tiff files compressed with the zip algorithm.

No offense to Andrew, but I agree.

That’s the whole reason people use .dds textures. .dds textures do decompress if they are not compressed with a dxt format. There are literally over a dozen other lossless options.

I understand that it would make sense to support this, that doesn’t mean it’s happening. Not supporting it is simpler than supporting it.

Also, there aren’t actually that many options for fileformats that also include mipmaps, and even then it’s simply convenient to be able to use these textures, especially for game developers.

Do you have any evidence of this or do you assume this happens?

For one, Brecht himself said they’re uncompressed for render. I’m indeed assuming that image editing, compositor and CPU renderer do not give special treatment to DDS files, because that’s the simple (and reasonable) thing to do.

As for the evidence (besides your testing):
The ImBuf structure is used across Blender as a generic container for reading and manipulating image data. It has a field called dds_data which exposes, unsurprisingly, the DDS data. The only area where this field is being used (outside the ImBuf module) is the OpenGL code where the textures are uploaded to the GPU.

Furthermore, the location where textures are allocated on the GPU is CUDADevice::tex_alloc. It shows no usage of block-compressed texture formats.

Ergo: Blender does not use texture compression outside of OpenGL display.

I haven’t tried ProSkies, but I did some tests with the SceneCity skies and they’re not good; they produce too much noise and don’t reduce memory usage, actually I think it’s the opposite.

I’d use SceneCity just for the city generation part, and ProSkies for illumination, it seems much more robust.

You can call it extra features but I call it spreading it’s self thin.

Two tests. First one is Pro Skies,
Second is a regular HDR.
I don’t see any difference.



@FloridaJoe
There actually shouldn’t be any difference.
Pro-Lighting: Skies is just HDR lighting made easier and more efficient. The value is that you don’t need to browse your harddrive to find hdrs and then fiddle with nodes. It does it all for you.