I’m glad that Luxcore is so fast developing and exceeds Cycles in count of useful features. I’m migrating from Corona to Cycles/Luxcore but there’s some features that are stopping me from using Lux (and Cycles that is lacking in other ares). So I’ve got questions about development of these features that I miss from Corona most:
what are plans for Ray/Path visibility and Bevel and Dirt shader? Are they coming for 2.5?
also, are there plans for new features for tonemapper - things like filmic highlights/shadows, highlight compress, image sharp (similar to FStorm/Corona tonemappers) and streak glare?
Besides, are portals obsolete if I use Environment Light Cache reworked in 2.4?
Cycles Bevel traces rays inside a shader and that is something is not currently supported in LuxCore and will not for any foreseeable future (it is a very bad idea for GPUs). However Bevel could be implemented by other mean.
At the moment, people are just backing the Bevel with Cycles and than use the backed texture in LuxCoreRender (remember that Cycles Bevel is a trick like normal bump mapping, not a real geometry Bevel).
Any render engine in Blender return just an HDR result so it is more a feature to add to the Blender composer than to LuxCoreRender.
We can, and we do, apply effects (i.e. denoiser, color aberration, etc.) to the returned image for some post processing so we could workaround some feature Blender may lack.
Yes, they are (as far as I remember, Corana has a similar feature and doesn’t use portals anymore).
Too bad about the Bevel shading. Damn. But maybe I’m just too greedy. Cycles worked well so far, it will in the future. But I will keep watching the development of Luxcorerender.
It is already embedded in cloth material, metal, etc.
I assume Cycles AO uses exactly the same type rays-traced-inside-the-shader technique of Bevel shader however, again, it may be implemented by other means (i.e. using the distance from last path vertex, without the need to trace any additional ray).
Dirt shader: may be, depends on what you mean and how it can be done.
Hi guys. Why GPU viewport extremely slow (compared to cpu vieport). I have ryzen5 2600x and rtx2070super. cuda mode. for final render it works good. GPU faster. But in viewport GPU extremely slow. I cant even rotate hdri 2400x1200pix without lags (using GPU). In cpu hdri rotation works super fast without any lags. Is this a bug? Maybe some settings can fix GPU viewport speed?
It works almost the same with the Fallof node in Max (Vray/Corona/Etc)
As far as I know, Dirt and AO shader are the same, isn’t it?
The thing with AO/Dirt shader is that it can be used on separated flat surfaces (different objects), unlike the pontiness (I used Pontiness only with Cycles, so if in Lux it works in other way sorry)
I work with CAD models where it’s better to add bevel shader than adding bevel modifier (it is heavy and can ruin everything). And I use triplanar mapping because it’s hard to unwrap those big, complex CAD models (and baking bevel would be tedious or not practical because of texture resolution)
So my workflow looks like this: using everywhere bevel shader to add fake rounding (results are great) and project texture without unwrapping. Corona has bevel shader and triplanar. Cycles has bevel shader but doesn’t have decent triplanar mapping and I spent time for some hand unwrapping. Lux has pretty one true triplanar but bevel shader is missing here. Many artist just throw bevel shader everywhere for those rounding that are natural everywhere and it adds realism as it shows specular on edges.
What I love with Luxcore that tonemapper effects are showing in real-time that is great in comparision to slow Compositor so that why I asked about possible new effects
I don’t know of any. I can find hitpoint info/shading normal and a dot product node, but nothing to plug into the second input. In Cycles, layer weight/facing is equal to 1-dot(normal, incoming). We don’t need fresnel, as it is included in the shader components and it only has one use. The facing pow 5 + offset is a good enough approximation.
So what is a good example of using the dot product node in Lux? I’m lost, lol.
Not built in, but there are several approaches. The simple coordinate scrambler may be good enough if you don’t use bumps. I use simple box mapping which fails at very low normal blends. I also have a complex version for 3 and 6 normals that doesn’t fail but is pretty expensive to compute. The node setups for all these can get visually complex as each texture has to be setup as flat projections separately in all directions, then mixed with the triplanar node. It does allow individual z rotations though which is a huge bonus, and does work with 2D procedurals. I’m still using the simple builtin one for image textures if I have the luxury or manipulating the objects coordinate orientation, or use UV sector checks to pick empties to drive object coordinate orientations. It’s crazy that coordinate rotations fails for box mapping
Cycles doesn’t have a Triplanar Mapping node but with it’s impressive amount of nodes, it’s not hard to create one. I use Triplanar mapping with Cycles for a long time now. But of course a dedicated Triplanar node is preferable and easier to handle.
The massive amount of nodes and the possibilities that come along with it, is one of the big reasons - maybe the biggest one, users are not switching to other renderers that easily. Often each of them has some crucial features missing, that makes the switch just that little bit too hard to do. Depending on what kind of work you do this can be different reasons of course. Octane Render misses the flexibility in projection mapping and randomization but has a Bevel edge option. Luxcorerender doesn’t have a Bevel shader but might be able to handle to projection mapping randomization ( I would have to check that in time).
So while Cycles does seem to be idle in improvements on render quality and features, it’s just a very powerful workhorse which can solve almost any technical hurdle.
@AndreasResch you are right cycles is the workhorse and Luxcore makes it looks good. Here are 3 node groups for cycles. A good workflow for Luxcore is to bake everything on maps and use the cycles scene reader. triplanar.blend (88.9 KB) my favorite is principled baker
Baking is fine when you have just a few objects. But as soon as you move into the dozens or hundreds, it becomes too time consuming. So I stay away from baking as often as I can.
Since the cycles node reader I have not looked at the nodes in Luxcore. It’s quite possible that the one or other triplanar cycles setup can be easily recreated in luxcore. I would be interested if you try.
This is the simple setup I use in Cycles that fail with small blend amounts, so might want to prevent that. Also it uses internal Geometry/Normal instead of being exposed to be used with bump/normal map outputs, as Cycles can garble the input socket data if nothing is connected.
You can also go amok and noise modulate the normal to better hide the transition “seam”.
Stay away from the coordinate “fake blur” approach some use, as bump elevations are not blended and will cause extremely sharp transitions within the seam. Due to neighboring pixels being from different maps.
especially for interiors.
Here are 3 node groups for cycles. A good workflow for Luxcore is to bake everything on maps and use the cycles scene reader. 