3Delight Messages
broncomech
Posts: 0
I have noticed an error message every time I render, just wondering how to fix the issue.
I do end up with a rendered image but it seems to take a long time and the image never matches the preview window.
Many times the preview has better detail and color than the render.
3Delight message #141 (severity 1) D2045: pixel filter reset to box
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
I doubt that has much to do with the speed or the way the render looks. It just means that the setting for Pixel Filter in Render Settings doesn't work with some of your other settings. Posting a screenshot of your scene and your render, or cropped versions thereof if needed for TOS-compliance, may allow people to offer some advice - a screenshot of your Render Settings>Advanced tab may also help.
pleace
Try rendering a single primitive - does that look close to the preview (the preview is never going to be exact) and go quickly? I suspect you are rendering a scene that's too complex for the preview (more lights than are supported, shaders that don't show in preview) and that accounts for both the slowness and the different appearance. The error is not serious and is unlikely to account for big problems with the render.
I have the same response "error message"
3Delight says this about the error:
D2045 PixelFilter reset to 'box' 1x1 (display driver requirement)
The display driver cannot accept the specified pixel filter. Forced to 1x1.
The only display driver that could do this is the `dsm' display driver.
************************
This tells me the display driver can not work with the pixel filter I specified,
but does not offer tuning suggestions. Which display driver are they talking about?
The 3Delight software driver?
************************
Bucket Order = Horizontal
Bucket Size = 16
Max Ray Trace Depth = 1
Pixel Samples (X) = 4 (which is 2 times the square root of the Shading Rate)
Pixel Samples (Y) = 4
Shadows Samples = 32
Gain = 1.00
Gamma Correction = Off
Gamma = 1.00
Shading Rate = 4.00
Pixel Filter = Sinc
Pixel Filter Width (X) = 6.00
Pixel Filter Width (Y) = 6.00
Scene is a sphere and a torus with 1 camera and 2 lights
a distant light and a spot light.
the sphere is textured with the "simple skin" texture included with DS
the torus is textured with the marble texture included with DS
My PC is a Samsung Series 3 with and AMD A10 Quad Core
Trinity Processor and 6GB RAM.
I don't have that error with those settings. Though a shading rate of 4 is very high and will give a poor image.
Hi Richard thanks for taking the time to reply:
Well I deleted both objects and both lights.
Set shader rate to 2.00
and pixel sample to 3.00
STILL get same error.
Tried closing and restarting DS and STILL get same error.
*******************************
Just tried another restarted DS and did a render with only the default camera.
Did not load previous scene.
SAME ISSUE.
Reset render to default in a new scene with primitive sphere did nothing to it.
Ah ha only comes up when I check progressive rendering (even with default settings).
i copy from 3Delight Developer about that error message
-
You are probably using a deep shadow map for one of your light sources. For the particular render, the pixel filter width cannot be larger than 1 so it is clipped. Not a problem really.
- Aghiles.
-
Your final render is not affected. We will make sure to output a correct filter width for the shadow maps so that you won't see that message in the future.
- Aghiles.
source
http://www.3delight.com/en/modules/PunBB/viewtopic.php?id=344
Which version of DS? The display drivers are files in the \Displays folder in the application folder, I think (but with limited confidence).
Ah, I didn't have any DSMs in my test - but putting one on the Distant Light didn't trigger the warning.
DS Pro 4.6.1.17 64bit with only default plugins
Oh yeah Win 7 64-bit
Is DSM a deep shadow map. If so, I do not think I enabled that but I will check.
Also that final test had no lights in the scene just the default camera
Okay it took me a bit to determine where the shadow mapping was.
In the original scene I did enable Raytraced (software only) in the settings for both lights and i set
the softness to 50% and the bias to 2.00.
But in the scenes with no lights obviously I did not set anything. So swami what does your crystal
ball suggest? :-)
Okay I just confirmed this has nothing to do with DSM. I created a blank scene added a default camera,
sphere, spotlight, and rendered. I made sure neither dsm or raytrace was chosen.
Without progressive rendering I don't think I saw an error message. It goes by pretty fast.
With progressive rendering it happens.
Okay this is definitely related to Progressive Rendering and which settings I choose inside PR does not improve the outcome.
If I turn off PR then it renders using SINC.
So this bring up the question, what is the benefit of PR. Should I just leave it off? Will that effect the quality of final renders?
This is a Mac OS X issue with the graphics driver. I have the same problem whenever I enable Progressive Rendering.
Alas, until Apple release a new PLM and OpenCL driver we are all stuck with it on OS X......[sigh].
Considering it didn't seem to happen in previous versions, I suspect they can fix this DAZ soon.
I could be wrong in my diagnosis and I am open to alternative ideas. Maybe DAZ Studio 4.6 renderer is not compatible with the AMD Radeon HD 7660G + 7670M Dual Graphics
I did try 7670M solo and the dual graphics option.
Maybe.
I have an iMac with an ATI Radeon HD 4670 512Mb that throws out that same message but it still renders OK and in a reasonable time.
I also have a Windows 8 machine that seems to be fine with "Progressive Rendering" set to on and it's no faster than the iMac.
I looked it up on the Mac Forums as well as speaking to a mate an Apple Genius Store and would appear to be an incompatibility between DAZ Studio, 3Delight Engine and the Mac video drivers, including OpenCL. But I can't be more precise than that.
This is definitely an issue for the techie boffins......LOL
I have had this problem (and reported it to Apple, and filed a support issue with DAZ) right from the beginning when I was running OS X 10.6, and still have it with OS X 10.8.5.
God know what unknowns will appear with the release of the new OS X 10.9 Mavericks today, I shudder to think.
Progressive rendering starts by rendering a crude version of the scene, then goes back and fills in a bit more fine detauil, then again and so on until it reaches the end point (what you would get without progressive rendering on). It's benefit is in letting you see the whole scene rendered quickly, if crudely, so that you can assess over-all composition, the way the light and shade are falling an so on, without having to wait for a full final render. There's no point in using it for final renders.
Generally this happens if you are using the "Progressive Rendering" option checked in the Advanced Rendering tab. It can generally be ignored.
Thanks to everyone for their feedback.
So does this mean the "sinc" vs "box" pixel filter method has no impact on the final render and is just how the renderer goes through its crude to finish rendering iterations?
And therefore my final renders will be fine even if I have progressive render turned on and get the error message.
Or if I want good final renders then I have to leave progressive render turned off.
Progressive vs non-progressive do things in a different way. So its not a matter of "good" vs "bad" its just a matter of different.
Progressive vs non-progressive do things in a different way. So its not a matter of "good" vs "bad" its just a matter of different.
Can I infer from this that the quality of the render will be the same but with non-progressive it might render a bit faster and with progressive I get to see it doing the render in case I want to get an idea of the outcome and possibly stop it before it finishes?
Can I infer from this that the quality of the render will be the same but with non-progressive it might render a bit faster and with progressive I get to see it doing the render in case I want to get an idea of the outcome and possibly stop it before it finishes?
The quality should be similar. If you're in 4.6.1..17 or later, which one is fastest depends on the complexity of your scene (progressive begins to beat standard as the amount of geometry increases). They both have the strengths and weaknesses so its situation dependent. If you want to read the specifics you can check out 3Delight's documentation. The progressive render is using the ray trace hidder, the non is using the hidden hider (Reyes).
**************************************************************
Is this the documentation you mean?
http://www.3delight.com/en/uploads/docs/3delight/3delight_39.html#SEC159
http://www.3delight.com/en/uploads/docs/3delight/3delight_52.html#SEC205
http://www.3delight.com/en/uploads/docs/3delight/3delight_12.html#SEC19
If the Progressive Renderer is switching the Pixel Filter from SINC to BOX, then this seems to be an issue if you want to use progressive rendering. According to 3Delight:
filter filterwidth window Comment
box 1.0 - This filter tends to blur textures. Use only if texture generation speed is an issue.
triangle 2.0 - `filterwidth' larger than 2.0 is unnecessary.
gaussian 2.50 - A good filter that might produce slightly blurry results, not as much as the box filter though.
catmull-rom 4.0 - A better filter (producing sharper textures).
bessel 6.47660 `lanczos' Filter width chosen in order to include 2 roots.
sinc 8.0 `lanczos' We recommend this high quality filter as the best choice. Although it can produce some ringing artifacts on some textures. Using a `filterwidth' smaller than 4 is not recommended.
Table 3.1: tdlmake filters.
From this table it seems Box makes a blurred version of the render compared to Sinc?
I believe its these docs: 3delight Docs
The pixel filter is not the same as the tdlmake filter.
thank you DAZ_cjones for taking the time to explain this to me.
I grabbed the PDF you mentioned. It is the same document.
When I did a search for any explanation of the Pixel Filter settings it only came up with the 2 error codes D2045 and P1041.
The point I am trying to clarify is that my renderer is generating an error code D2045 which indicates it changing the pixel filter from "sinc" to "box" when you do progressive rendering. Why is it doing that? Is pixel filtering used in non-progressive rendering (REYES)? The table I refered to explains the differences between filtering methods. Why would it not apply to pixel filtering equal to application in texture optimization?
Table 3.1 is in reference to tdlmake filters would not the quality variance apply to the pixel filter too?
tdlmake is just a command line texture optimizer that inputs image files and converts them to TIFF files optimized for the renderer.
****************************************************************
It seems the basic difference between Ray-Trace Hider (progressive renderering) and REYES (non-progressive rendering) is:
The ray tracer is slower than the default REYES renderer but it could prove useful in some cases:
1. No "eye split" problems. Primitives that are difficult to render using the standard algorithm can be rendered in the ray tracer without problems.
2. Motion blurred mirror-like objects will have good reflections. This is a classical problem in REYES renderers where shading is done only once for a mirror-like objects, meaning that motion-blurring the mirror will blur the reflection, which is not the correct behavior.
3. Can produce nicer refractions and reflections since there is one shading point per subsample and not per micro-polygon.
**********************************************
I have not used Deep Shadow Maps (DSM) or Ray Traced Maps and still the problem persists if I use the Progressive Renderer.
Seems like the docs may be behind. See comments in Release Notes. Studio's version of 3Delight is "10.0.170" which is after they did a lot of the speed improvements on the ray trace hider. You may also want to see Press Release.
thank you DAZ_cjones for the links.
I have now read those documents and I can see they have improved progressive render alot.
My question still stands.
Why is the progressive render changing my pixel filter from sinc to box (which will still provide a blurrier image than sinc)?
Does this also happen in REYES (non-progressive) rendering? Is REYES even affected by the pixel filter being set to sinc or box?
In terms of box being blurrier than sinc for sharp renders, even Age of Armour refers to this:
http://www.ageofarmour.com/3d/tutorials/AoA_metalized_glass_shader_help.html
QUOTE:
"For most of my work I use Sinc filtering with X and Y filter widths set to 6. However, rendering highly reflective objects in a HDRI environment can sometimes produce jagged pixels around the reflections of very bright lights. This is because the renderer notices that the reflection of a light in a HDRI might be 100 or 1,000 times as bright as the area around it. To represent this extreme difference, the render filter sometimes enhances the contrast between these two areas with a black band.
In these cases the jagged band around highlights can be lessened or removed by using Gaussian filtering with a pixel width of 2 for both X and Y. The difference is subtle and may slightly decrease the overall sharpness or the render but this, combined with increasing the Reflect and Refract samples to 2 or 4 in the shader can produce some very nice images."
Is there nobody out there who can answer my questions?
3Delight would be the best people to ask. I want to say the pixel filter doesn't matter on the ray tracer, but you'd need to confirm it with them.
It certainly is. But it does not change it automatically to box.
It certainly is. But it does not change it automatically to box.
Thanks to both of you for responding.
Well it took some learning and fiddling around with DS, but hopefully the attached images will demonstrate my concern about the reset to box filter. Both renders were done with same setting. The progressive render engine reset the sinc filter to box as was discussed at the beginning of the discussion.
Please see attached.