[RELEASED] Deckard Render - Cinematographic Renderer for Unity

No, I don't think so. I'm trying to give a response in limits of a 14 days (as per Assetstore EULA), but not for everything. I am a single developer, so I really don't have a time to respond to questions that are trivial or already responded (yeah, I know, I should have some Q/A system that can filter questions) or asked without giving any important information. Sometimes I will respond in 5 minutes, sometimes I will respond in 10 days..
I'm planing to release a Deckard Render Pro, that will cost 400$ and will give a 4 hours of direct video support/training. I don't wan't to rise a pricing of Deckard Render as it is (and it is low), as I understand that it is a valuable tool for many independent artists. But, due to many projects that I'm working on as a single developer, I don't have enough time for responding to all questions, or to some questions that were already responded. For most of the problems, you can always spend few hour watching videos where I'm explaining many things about Deckard (and beyond).
Also, if you make a good question with info that can help me out in understanding what is your actual problem, I will always try to respond ASAP.

No, you can't get a refund for this, sorry. I have to be frank and say: Any refund requires some of my time, even an hour in few days, and a price of Deckard is less than an average one hour work. If you want to try it, it is better to contact me, present yourself and ask for a free test version. I'm more willing to give away a free version than spending time asking for a refund, and/or following up on a case.
As I've said, I'm a single developer/creatore, and I'm currently managing support for 3 assets.. soon will be 4 with my Deckard Chromakeyer. I usually work as hard at supporting my latest asset, so that who needs and answer can find it in forum. And so that I can track all possible bugs. Deckard is currently one of those assets that I'm pretty found of supporting - thru forum or thru youtube.

 

Thanks for all the answers and your time @olix4242

Will there be reduced cost upgrade path for existing Deckard Render users, to Deckard Render Pro?

I'll send you a PM for the free test version......

 

@olix4242 I wanted to ask about the bitrate settings in Deckard. I noticed the default bitrate for 1080p is 8000, but in your streams you render at 22000 bitrate at 1080p. What advantages are there for doing so? Also, do you think rendering at 2k vs 1080p would really matter that much for movies? I would probably render at higher resolutions if I had a powerful enough rig, but I'm just curious to know if I'm possibly missing out on something by choosing 1080p instead of 2k and beyond

 

Hi, this is actually a good question, and something about what I have already planed to speak about on my youtube channel. There is a lot of confusion about resolution and different approaches and use cases and a problem get's pretty messy as you go down to a rabbit hole. So we have to understand that image resolves at more stages (and here I will use the analogy of real digital camera vs. CG generated image (Deckard/unity):
-Optical stage (in a real camera, this would happen in a lense, in Deckard, this happens in it's own physical simulation of a lens)
-Sampling stage (in real camera, this would happen on a sensor, in Deckard this happens internally)
-Capturing stage (writing to a video file)
-Displaying stage (reading a file and showing it on a monitor or a theatrical screen).
Final image resolution (ability to solve small details) depends on all those stages.
In physical photography (or still image print) resolution is a mostly a simple thing. You know what is your final support size, and you just print at a requested resolution.
In motion picture, this gets pretty complex fast.

Optical stage in camera - a capacity to resolve resolution is based mostly on your lens and film/sensor format. There is no such a thing as a perfect lens, and any lens will introduce some kind of physical blurring (that happens due to unperfects lens surface and other characteristics that are more physically complex), depth of field, and motion of a camera (motion blur). In Deckard, we have a camera that mostly has a lense that is capable of doing DOF, but it doesn't have any lens imperfections.

-Sampling stage in digital camera: This is where things get tricky in a digital camera. Most CMOS cameras actually doesn't have a fixed resolution (even if they state values like 4K or more). As a Bayer sensor almost always consists of a 'pixels' that actually aren't real pixels, but are so called photo-sites. Each photo site can sample only one color (R, G or B). So you need actually 3 photosites to sample one color. This means that a sensor will be able to sample a full resolution only when your real scene is made of black, grays and whites. This also means, that any color that isn't in a grayscale, will have it's own relative resolution that less that 1:1. For example, any full red (or green or blue) color will be sampled at 1/3th of a resolution. If you have a camera, try putting a red filter in front of a lense (or filming under red light) and you will instantly notice resolution downgrade of a third of an original resolution. To this, you should add a problems with a noise - most cameras will use some kind of a denoiser that actually lowers resolution even more. Some will feature sharpeners, but they mostly only give a perceptive gain in crispiness, while they are actually downgrading resolution (I know that this seems counter intuitive, but it's a pretty complex thing to explain here).
-Sampling stage in Deckard: It is done without any problems related to image samplers (sensors) in real camera. Actually, I had to add some artificial noise to make an image look and behave more organically. Also, it captures all colors at a same resolution. When using Deckard, you are actually getting a lossless resolution at this stage.
-Capturing Stage in digital camera: This pretty depends on what file format are we using. If we aren't using RAW, we will have some resolution downgrade due to Chroma subsampling (the practice of encoding images by implementing less resolution for chroma information than for luma information) More about that here: https://en.wikipedia.org/wiki/Chroma_subsampling
-Capturing Stage in Deckard: This depends on format and compression. Capturing here is done or in full floating point RGB (when using EXR), in PNG (full RGB) or in a JPG (that uses variable subsampling).

Delivery of a file is a different beast: you can deliver in mp4, and depending on your quality (bitrate) settings you will get a better or worse image. One of the tricks used by many, when delivering to youtube is to record in fullHD, but then just resample video to 4K and export it like 4K. This is something used also a lot even in cinema.
Should you care too much about resolution? It really depends on your content type. For example, a scenes that are static and sharp could be rendered in higher resolution. Those with lot's of motion can be rendered in lower resolution. Images with shallow DOF can be rendered also at lower resolutions and then scaled up for final delivery.

One thing to know: A HD resolution rendered in Deckard is more like a 4K resolution captured with a professional digital camera - so if you have to match content from a real camera, don't try to match resolutions - as a Deckard actually has better optical resolution than a real camera. (this is also why I have introduced Use Half Resolution).

Last but not least: never compare a resolution concept that we have in gaming that "a bigger resolution (and framerate) is better". Gaming is a different medium than cinema where "quality values" are actually inverted. In a gaming you want a bigger resolution as it helps solving aliasing issues. You also want better framerates because they help solve the temporal aliasing issues and all this to be able to reduce latency, realtime fluidity and precision. In cinema this is something that isn't wanted and desired. We are still using 24FPS as a standard, and most of a movies (done on film) doesn't have a resolution that is greater than FullHD (actually, many analog movies have much smaller actual resolution).

 

@olix4242, what fantastic opportunities you're singlehandedly bringing for TV and film Devs on unity.

Keep up the incredible efforts!

 

Thank you for the detailed response, that was very insightful. It seems that rendering in 1080p HD is perfectly reasonable for film making. As for 24fps vs 30fps, is there any disadvantages to rendering in 30fps? I have heard mixed information regarding this, some say they stick to 30fps because it looks slightly smoother. The only downside I can think of is the slightly longer render times. However, I am unaware if there is any technical reason for choosing 24fps in CGI

 

On

Only advantage on choosing 30fps is that most computer monitors (or TVs in USA) use a refresh rate of 60hz so by deploying 30fps video to youtube or social media you don't get a stuttery video as it's gets synced correctly. But right now, we have more standards, from 75fz to 200 and more. So this isn't any kind of a standard. I personally prefer 24-25 fps as this looks most 'cinematic'

 

Ah I see. I might actually give 24-25fps a try next time, thank you. I have a few more questions that have always been at the back of my mind:
1) Is there any reason to keeping Deckard Outdoor AO light size to 75.67 x 80? I have 1 outdoor scene and I noticed I kept changing it slightly per camera shot to go for a certain look. With less light size, there are sharper shadows and sharper AO compared to the default 75.67x80 size. Is it better to not change light size to retain outdoor lighting correctness?
2) Is Deckard's lighting physically accurate compared to something like Octane?
3) When to use precise timing? I believe this is for particles and physics engine simulations, but in what situation shall this be used? I haven't had any problems rendering cloth simulations so far, but I'm guessing using precise timing would mean being in sync with timeline?
4) Is there going to be a way to animate Deckard render component fields? Like sensor size, aperture, focus speed etc. There seems to be no way to control these via timeline animations

 

No, there is not. It was a value that I've found to work well for my testing scenes, and I left it like that. Those numbers are actual angles from where a light spreads, so they can be anything.

I don't think that there is such a thing as physical accurate lighting in any renderer (if it's not based on quantum physics). And don't think that you even want it. If you watch my Youtube channel related to Deckard, there you will see why it is realtive and why it actually really doesn't matter. But it's a complex thing to resume in few words.

This is an obsolete function as this worked only for particles. Right now it should be substituted with Safe Rendering mode.

Aperture is animatable. Others aren't ( I'm supposing that an sensor size shouldn't be animatable - but I can eventually expose it). Focus speed isn't animatable, but it shouldn't be by logic. If you want to animate focus, just use focus distance instead of focus speed. Focus speed is more for autofocusing, and it's pretty unprecise method of focusing - compared to automatic focus camera.

 

Ah thank you. I was initially trying to right click to 'add key' and it didn't show the popup menu and I thought it wasn't animateable, but now manually changing the values with record mode on seems to work.

 

I have finally found out when it happens and why I couldn't reproduce it for months.
This will happen if you don't have selected Gizmos box in a scene view. This is essential for Deckard to work correctly. As I never turn it off, I wasn't able to reproduce this problem. (practically, deckard uses a hack to force refreshing of a screen view, and this hack uses gizmos - so If they are off, it simply doesn't work).

 

IS THIS ALL?! XD

LOL, I've struggled with this for... idk, too many hours anyway. It took me quite some time to read everything in this forum, because I didn't want to bother you without trying hard first. I (almost) never enable gizmos, unless I'm looking for something specific in the scene that wouldn't be visible otherwise. Guess I'll start now, and see how it goes, since I tried pretty much everything else, with apparently random results.

Later today, I will hopefully have some time to test again (this is not my job, or I'd start right now) and I'll let you know the results, together with any relevant information (I think I have a clue after all this reading lol).

Thanks and congratulations on your great job with Deckard. It's been giving me good results even with little technical background and low-to-none optimisation (I struggled to make it work, so I didn't focus on details). I can't wait to test it at its full!

EDIT/elaborating:

I confirm that this seems to solve.

Yesterday I had one more "blank screen" case, but tbh, I had my main camera all messed up and I remade it from scratch. Then, with all the default settings, it worked like a charm. I would have loved to gather more details, but when I saw it working as expected, I was too excited and I let it run for roughly 5 hours to render a 53 seconds animation. I didn't feel like debugging at 2AM lol.

Now, before doing a few more tests tonight, I have a couple of questions/notes. The test had a few minor problems (nothing that can't be solved, but I'll probably need a hint) despite being beautiful – for my uneducated eyes at least. A couple of pink prefabs apart (I already solved the shader issue), here are the issues.

1) 5h seems a lot for 53 seconds, do you suspect something is wrong, or is it expected? The animation had standard settings: 1080, 24fps, no strange 3rd party filters or anything. Only non-default things was the physical camera setting on Deckard, set to IMAX and Kodak D65 (IIRC).

2) The terrain (or maybe it's just the grass, hard to tell for me) seems to tremble, maybe an issue with the timing of Deckard vs the animation? It's made with an external tool (Pegasus), which was set to work specifically at 24fps (it's one of Pegasus' settings). Do you recommend turning it into an animation with Recorder and trying again? Should I use "precise timing" in Deckard?

3) Some grass and rock meshes look like they are changing LODs randomly, or at least that's the only thing I can think of to justify the fact that they transform in front of the camera. Can this be related in any way to Deckard and some of its settings?

Notable informations: the scene is made with Gaia Pro and navigated with Pegasus. Not yet optimised in any way, it's a 4x4kms area made of multiple terrains at maximum detail level. No other assets involved in this scene yet. I plan to optimise it only when it's finished (or close to finished). Now it's heavy, even for normal game mode.

Which leads me to question 4: I plan to use Unity basically for videos, and mostly in open areas; are there optimisation techniques that you feel like suggesting? Something I should NOT use for best results?

Tonight I plan to do some more tests, this time with maybe 100 frames, not 1200+ lol. xD

For reference, a link to my first test, unedited.
https://drive.google.com/file/d/1AOhXsjyBeyEY2N3R1zAOsjDI2E-vn4d5/view?usp=sharing

 

Sorry for the double post, but I wanted to make sure you got a notification.

I am extremely happy to confirm that this one thing singlehandedly solves all the "no camera rendering" issues for me.

Also, I had a chance to debug (at least a little) for myself the issues I pointed out earlier.

Issue 1 seems to be related to the scene optimisation. A smaller and more fluid scene renders almost in real time, with results that are more than acceptable for me. Despite being less nice by default, Deckard seems to make it good-looking anyway. BTW... my previous scene in game mode ran at roughly 30 fps. The new one ran at 300+. It's the only difference, and the rendering times changed by a factor of roughly 200.

Issue 2 and 3 DO seem to be related to what I suspected. I will re-read the forum thread in search for more details and tips. It might be time for me to learn how to use animations like the big boys lol.

And now allow me to propose what I consider an important suggestion for you.

Please, add all the obscure knowledge in this thread to the documentation. It's the single best thing you could do for this awesome product of yours. Possibly also links to scripts/shaders/whatever file.

The value of Deckard would skyrocket, due to the improvement in its usability - even by relatively unexperienced users.
Think about it. Thanks.

 

Keep the LOD that you want (eg LOD 0) and disable the rest because you won't really need them anyway since Deckard is an offline renderer.

 

Has anybody managed to get Deckard Render to work with mudbun? Mudbun opens a whole lot of possibilities for motion graphics.

 

No, but I did some tests with a trial version.
Apparently MudBun has it's own problems, as it doesn't support image effects (standard PPS) and this is essential for Deckard to work correctly. I suggest you to contact a developer and ask him to implement compatibility with post processing in a standard pipeline.

 

It is known that some grass that uses custom shaders could tremble. This is due to grass system in unity (or custom shaders) not respecting time scale in Unity but running on it's own. In a first case (unity grass) it is a bug in Unity that exists for years. In a second case, it is improper programming of custom shaders/scripts. What happens is that grass moves faster in final animation than it should. As any timing system in Unity, grass should be synced with value of time.timescale, that says internally to all systems what should be a speed at witch unity runs it's internal clock. For example, if you set timescale (in time setttings) to 0, then every system should stop. If you set it to 2, then every system should go 2 times faster. When you set it to 0, if a grass still moves, than that means that there is a problem in a system that is using it (be it grass, or custom shaders).

 

You can force maximum log with a script that I posted here:
https://forum.unity.com/threads/rel...enderer-for-unity.624439/page-14#post-6470954

 

Thanks, there's no way I could remember that post. You're the best.
Tonight I'm going to test this, together with higher resolutions (it's almost mandatory for my very specific use case).

I'm just worried about performances. Is there some reason for avoiding other performance-related techniques? Like, for example, instancing or occlusion culling? I guess combining materials and meshes shouldn't be an issue, but what about those? (if this sounds like a noob question, well, that's because I'm a noob lol)

Thanks!

 

No, Nothing against those techniques (occ. culling and instancing). They are always healthy and have only positive impact (as they would have in engine). Almost anything that is in Unity is compatible with deckard. You can only get some undesired effects from some systems that are buggy already in unity (but, fortunately, Unity did solve many of them from a first release of Deckard). Others that you could get come mostly from third party plugins.

 

Thanks, I made sure to leave a well deserved 5-stars review.
In the review I also suggest people to enable gizmos, so hopefully the problem shouldn't arise anymore.

When you have time, and of course if you feel like to, it would be nice to new customers if you said this in the asset description, or in an updated documentation.

Just so you know, on an optimised scene my computer renders 24fps, 8K (!!!) videos at an average rate of a couple of minutes per second (a little less if I disable noise, or is it my imagination?). I didn't track the exact time (someone let me know if it could be interesting) but it's just to give you an idea.

Spoiler: MY SETUP

• Intel i7-10700f
• NVIDIA RTX 3070
• 64GB RAM

Which is a perfectly fine pace, since I would hardly need more than 10, maybe 20 seconds per render. I have no idea of the rendering times of other similar softwares for a comparison, but I guess it's VERY good.

Nice, nice, nice job on this asset, my favorite purchase so far for my "work" flow.

 

I would be interested in this. But numbers dont say much unless accompanied by an image also, so we can get an idea of what you are rendering. (I'm sure 3 cubes will render faster than a full on complex scene for example)

 

https://drive.google.com/file/d/11QR28DarBd8a0K9T9rB9KZppGy5WXu82/view?usp=sharing

Nothing too complex, but not a couple of cubes either. This is the demo scene of a Nature Manufacturer asset.

Spoiler: PBR Graveyard

https://assetstore.unity.com/packages/3d/environments/fantasy/pbr-graveyard-and-nature-set-2-0-58915

I didn't touch it except adding fog, a dragon from Protofactor, changing the illumination to night and toying around with a few visual effects on the camera (EDIT: in this example I disabled noise in Deckard). And since Nature Manufacture JUST updated the asset, I can't wait to try the updated version. The one I used was quite old.

Later at some point before going to sleep, I'll record the screen during a similar rendering.

LAST EDIT I PROMISE: the barely visible white grid you see on the ground is added by another asset, and it's not exactly the most lightweight asset I have lol. It covers the entire terrain, and slows down everything.

 

Correction on the previously provided data. Being inexperienced, and experimenting mostly at (late) night, I probably got confused. Or maybe a slight change in the scene (the dragon now moves along a path) is heavier than expected. But I want to err on the safe side. So I will assume that I was just confused. Anyway...

I started the rendering at the 3 resolutions I find more interesting, and calculated an average after getting 10 frames. My experience with Deckard so far suggests that this kind of estimation is a good approximation (for loops at least).

Assuming 24fps videos, I get roughly 5 seconds of footage in:

3 minutes when working FHD
5 minutes in 4K
90 minutes in 8K

 

Rendering speed is simply calculated: if your scene renders at 140 fps (at given resolution that you want to use with deckard), you will end up with Deckard rendering it at 1 fps (one second per frame) at default rendering quality of 70.
You should actually divide your realtime FPS with quality value in deckard multiplied by 2 to get a your rendering FPS.
With default settings, with Deckard you have a rendering that is approximately 140 times slower that a realtime. With a quality of 50, it will be 100 times slower that Unity.
But be always sure to use Unity realtime in actual resolution, as Unity can drastically change performance when going from HD to 4k or 8K.

 

In 8k you get a drastically bigger times because you are hitting bottlenecks of you graphics card (probably Vram amount).
But why do you need a 8k rendering??? You don't even need a 4k rendering.

 

I don't strictly need it, but I'm going to use at least some of the renders in a scenario where they must be zoomable, and I need to lose as little detail as possible in the process. So 1080 is ok, 4K is good, but 8K would be ideal... at this point I'll see if it's practical.

Most videos will be probably rendered in FHD1080 anyway, only some would benefit from higher reolutions.

 

I got an answer from the MudBun dev:

"OK, just tested. MudBun does work with PPS (v3.0.3) in the standard render pipeline.

Then it becomes the question of why procedural mesh rendered with a call to Graphics.DrawProceduralIndirect does not get rendered in Deckard."

MudBun has a discord channel, do you think the two of you could chat about it directly?

 

As I was finally able to find what was the issue (gizmos selection) I've also got to find a solution for this issue.
Here is a patch for those that want to test it out before I submit this to assetstore.
https://www.dropbox.com/s/8yvc2seae7wb9ud/deckardrenderfix_a2.9.unitypackage?dl=0
What is inside this patch?
-"Progressive rendering" is completely being replaced with "Responsive rendering". This is a mode that saves GPU and adds responsive times in editor at a cost of slower preview (configurable with Batch groups option).
-Fixed a need of having to keep open Scene view
-Fixed a need of having to keep activated Gizmos
-Various performance improvements (just a fact that we don't have to keep scene view open anymore adds to a performance).
-New "Safe mode" rendering option. This was available in previous patch, but isn't available on assetstore version. This 'safe' mode improves compatibility with third party assets. It also helps on keeping HDRP GPU memory leaks under control and improoves a stability when using RTX raytrace.
-Fixed issue with some parameters being wrongly animated in timeline resulting in inability of rendering.


Soon after this version, there will be a new version of Deckard that will be adding some cool things for those that like filmic rendering:
-A new post processing system that adds even more convincing filmic noise.
-A new system for adding physical simulations of analog film beyond built in profiles. It is made to simulate properties of a film, film transfer, and cross processing. It is a simulation of physics that happen on a celluloid medium, physics that are responsible for pleasing organic filmic feel. This will be implemented by using profiles. This feature will then probably be followed by profiles that can simulate analog TV cathodic tubes and videotape - but on implementation of this I'm not sure if it can actually be of interest to anyone. So I will keep this as an option for later.

 

It is probably imagination Noise shouldn't impact rendering times in any way.

I see that your dragon doesn't have (almost) any motion blur in animation. How are you animating him? I suggest you to use timeline for triggering animation (and not a simple animator by itself) - this will force a correct rendering of motion blur.

 

Hi. Thanks for the patch. I'm trying to use it, but I'm getting these errors:


Assets\DeckardRender\Scripts\DeckardRender.cs(1199,54): error CS1061: 'DeckardSoftLight' does not contain a definition for 'lookAtVec' and no accessible extension method 'lookAtVec' accepting a first argument of type 'DeckardSoftLight' could be found (are you missing a using directive or an assembly reference?)


Assets\DeckardRender\Scripts\DeckardRender.cs(1201,39): error CS1061: 'DeckardSoftLight' does not contain a definition for 'lightTexture' and no accessible extension method 'lightTexture' accepting a first argument of type 'DeckardSoftLight' could be found (are you missing a using directive or an assembly reference?)


Assets\DeckardRender\Scripts\DeckardRender.cs(1207,159): error CS1061: 'DeckardSoftLight' does not contain a definition for 'mipLevel' and no accessible extension method 'mipLevel' accepting a first argument of type 'DeckardSoftLight' could be found (are you missing a using directive or an assembly reference?)


Assets\DeckardRender\Scripts\DeckardRender.cs(1765,21): error CS0246: The type or namespace name 'ReflectionProbeOptimizer' could not be found (are you missing a using directive or an assembly reference?)

 

Same here

 

I have tried all the patches:

https://forum.unity.com/attachments/deckardfastupdate2-0-9-unitypackage.634901/
https://www.dropbox.com/s/8uhqyzgigx8icxz/DeckardSafeRenderingMode_Alpha.unitypackage?dl=0
https://www.dropbox.com/s/8yvc2seae7wb9ud/DeckardRenderFIx_a2.9.unitypackage?dl=0

 

I've noticed some performance loss when using the soft light script on directional lights. Is that to be expected? However, the script attached to point lights doesn't seem to have any overhead. The performance difference i'm getting during the final rendering is basically:
soft light on directional light = ~1m20s per frame
soft light on point lights = ~12s per frame

Soft lights on directional lights also are a little slower in editor mode

 

Are you using HDRP or standard pipeline? And, are you using large area light angles?
There shouldn't be any obvious reason for this (also because at rendering time all lights will default to small area lights).

 

Are you using HDRP or standard pipeline? And, are you using large area light angles?
There shouldn't be any obvious reason for this.

 

It's just Pegasus again. It's been one of my first assets, since it makes movement pretty much idiot proof, graphically setting a spline path and a few parameters to move around cameras and other objects. (you set m/s speed, fps speed, rotation speed, what to look at, etc)

I didn't even bother setting up motion blur, temporarily at least. Once I'll have understood the basis of animations, timeline, possibly cinemachine (I remeber you didn't suggest it for usage with Deckard, but... I'm curious lol) and the like, I'll surely pay more attention to these details.

Actually... animating stuff seems to be my personal Achilles' heel. That, and even the most basic physics, but that's another story, for another time. Looks like I hit my first blocks. It had to happen sooner or later, good thing I feel kinda committed after roughly 3 months of spending money and time on my new hobby. XD

Is there some tutorial you would personally suggest to a noob about animations, timeline, etc? You look like the right person to ask.

Despite my low attention span, I have a preference for written material (rather than videos); and possibly, for practical and detailed examples that I can try quickly. If you can think of anything with these features, and feel like sharing a link or two, you'd have my eternal gratitude (for what it's worth lol). Difficult stuff doesn't scare me... repetitive stuff with tons of small details to remember isn't my cup of tea, but I can bear it if needed, it will be a patience training.

Thanks, have a nice day/night/whatever it is where you live.

 

I'm using HDRP in Unity 2020.2 and using the default outdoor ambient light size, i.e 75.67 x 80. I dunno if it's because the complexity of the scene. I've tried it in 2 scenes so far, one using terrain and lots of vegetation, and one simpler indoor scene with light passing through windows, the performance was more or less the same in both scenes for the outdoor AO light. If I keep a larger light size the performance is still the same

 

NEW Deckard v3 version is available on assetstore. It has new features (film simulation), bug fixes, better support for HDRP, and overall performance improvements.

 

Will it render faster, or is it mainly editor performance improvements?

 

From my tests on my system it renders faster. But really not sure how much faster. In some scenes I've got like 2X improvement in HDRP. Not sure if it applies to all scenes and hardware.

 

A render done with new version of Deckard Render and it's film simulation feature:

 

Just to give an update, it seems as if directional lights don't necessarily seem to be the only thing impacting Deckard's rendering time, but more so it's HDRP that is the root cause. HDRP seems to tank in certain situations for some reason, especially if adding more than 10 point lights, or having directional light in large scenes, then the performance suffers greatly. I don't know if Blender or C4D has this problem, but it's making me want to just switch over to those, just because HDRP seems very unstable with it's lighting and performance.

 

What version of HDRP are you using? I'm suggesting you to use latest version as some previous versions had big leaks when using directional lights. Actually, it was a sky that used too much VRAM and had memory leaks.

 

Which version you consider the latest?
Current 2020.3 LTS use HDRP 10.x
Current 2021.1 Tech Stream uses HDRP 11.x
Current 2021.2 Alpha uses HDRP 12.x

From that, I would say 11 is latest. Would you agree?

 

Will have to try it. Currently using version 10 as it is a most stable version. Will have to try 2021.1 and 11. I'm almost sure that 11 should be faster, but don't know about bugs.

 

Good news for a 2021.2.. it will introduce nVIDIA DLLS
https://developer.nvidia.com/blog/n...fnIyg1QN8KpzxIuz3Ez-QTSsAD0lA9TWsO0WF30M8YypM
This probably means a much faster rendering with Deckard.

 

Nothing.. 2021.2 breaks everything apart. It isn't suggested to use it until next notice. (some of the functionality that was working before, doesn't work anymore correctly in editor).

 

Ah, had me excited for a second there!

Hopefully not too major to get it all resolved

 

I'm using HDRP 10.x on 2020.2. It crashed many times during middle of rendering with deckard. I noticed that disabling forward rendering fixed the crashes and limiting point lights to 2-5 max, and using area lights for the rest helped, but it's still not an optimal way to work with lights. I would in some cases like to place many point lights but that seems impossible. HDRP and Unity just chokes especially when point light shadows are activated. It's a pity because Deckard does indeed render faster than Octane while providing amazing visuals, but at this point I would rather have stability and the option to place lights without worrying about crashes. I dunno if the devs at Unity will make lives easier for film makers or not, but I hope they do