At the moment, the node only retrieves the hit position and distance, but support for geometry normals and other attributes is planned.
Keep in mind that, while the node is supported in EEVEE and Cycles, the implementation for each one is quite different.
For Cycles, the node traces rays against the scene geometry, without any kind of material evaluation. This means that material transparency is not taken into account, so intersections against transparent geometry still count as hits.
For EEVEE, the node traces rays against the screen depth, similar to the screen-space ray tracing used for reflections, refractions, diffuse GI, and AO. This means it has the same limitation as those: it can only detect hits against screen pixels from opaque surfaces.
The upside is that masked transparency is taken into account.
Note, however, that once we have hardware raytracing support implemented on Vulkan and Metal, the EEVEE behavior should be very similar to Cycles.
Some topics that we have discussed but donât have a clear answer yet:
Should we add a thickness input to the node? Screen tracing discards hits based on a âthicknessâ heuristic. Exposing this in the node may allow users to work around some of the techniqueâs shortcomings. On the other hand, it may be a difficult concept to grasp for most users, and it would have no effect for Cycles.
Should we have a âfilter styleâ mode, where you just set a 2d offset and the ray always goes in the view direction (kind of like the Image Sample in the NPR Prototype)? This would simplify one of the most common use cases, and would allow a more efficient implementation in EEVEE. On the other hand, itâs usually best to keep nodes simple with as few options as possible.
Are there other nodes required to supplement the capabilities of this node? For example, itâs currently not possible to transform coordinates to pixel positions, which may help with some of the use cases for this node.
Should we expose some way to filter out objects from raycasts? For example, you may not want to get hits against transparent objects in Cycles. We could have something simple, like a âRaycast Visibilityâ toggle (like the ones for camera, shadowsâŠ), or something more advanced like âTrace Collectionsâ (similar to Light/Shadow linking). The downside of more advanced methods is that they may not work with the EEEVEE screen-space implementation.
The node follows the same behavior as the Geometry Nodes one. So when a hit fails, it returns Ray Length as distance and (0,0,0) as Hit Position. Would returning Ray Origin + Ray Direction * Ray Length make more sense? Is it worth having a different behavior?
Limitation, itâs expected.
As I explained in the main post, EEVEE uses screen-space tracing, so donât expect miracles.
This shouldnât be an issue for filter style effects (cavity, rim, edge detectionâŠ), though, since the rays should go in the same direction as the camera.
And i wonder how can we hit the suzanne behind the cube?Maybe we can shoot it twice and use first hit position as the second source position and so on. But for complex shape this wonât work. For example the curtain, so i think we should also have a ânon-selfâ option just like the opposite of âonly-localâ.
Furthermore, if the above effects are directly converted to ev rendering without any changes, the performance is almost unusable. It is unknown whether the performance of the NPR project after supporting hardware ray tracing can really approach the current performance in cycles.
Before that, users might need to create separate effects for cycles and eevee respectively.
Yes. If it is needed to obtain a decent EEVEE render.
User wonât be annoyed by one value, useless in Cycles. They will learn to ignore it.
If several were exposed that would be problematic, but one already used in EEVEE render properties.
That should not be an issue.
It is probably better to have a node offering the most potential by keeping it simple.
There were additions of Utilities nodes (closures, menu switch) in shader nodes.
If a filter menu can be created for a nodegroup, we could have advantages of both.
The use case will probably rarely request to filter out only one object. Indeed, a solution about collections would be more appropriate.
Not really. The concept of nodegroup assets became pretty common to beginners, by being present for hairs, GN modifiers and compositing filters.
It will be understood for shading nodes.
If you drop such node, people will probably try it for other use cases, too.
So, probably keep that, for after validation of this one.
And it will be probably easier to test its satisfaction, by sharing nodegroups.
Yes, for some crystal-like performance that requires penetrating itself, hitting the target and returning information on the other side, it seems that it can only be emitted in a single layer at present, or perhaps I havenât figured it out yet
In addition, for those who want to take effect on a specified target or eliminate any target, a selection mechanism is required: For instance, here the second square only calculates Susan and ignores the first square. As of now, the default emission of this light is for all targets on the path. However, sometimes it is desired that it only takes effect on specific objects. For example, from the perspective of performance and operational smoothness, in large-scale scenes with many objects, it is necessary to preset a specified target before the light departs. This is to avoid interference. Second, it does not consume too much performance and cause operation lag
Also, is it related to the scene lighting? Switching between the material preview and rendering modes will make a considerable difference in the result
EditorïŒThe material preview and rendering modes using EEVEE and Cycles respectively result in different outcomes
Try to include specific real-world examples of what youâre trying to achieve.
Obviously, we all would prefer to have every feature ever, but everything has an implementation and performance cost.
Especially in the case of EEVEE, we just canât have everything.
So, for example, we could have collections support in EEVEE:
One implementation path could be to render the object IDs and donât report hits against objects from other collections. But you wouldnât be able to trace behind those objects anyway, so it may not be that useful.
Another implementation could be to render all the objects from each collection to its own render target. That way you could actually trace behind objects from other collections, but thatâs going to have severe performance and memory cost.
Meanwhile, with a simple Trace Visibility toggle, we could just render the depth pre-pass for traceable objects first, make a copy, and then render the rest of the objects, which would have almost no performance impact, a relatively small memory impact, and would still allow you to trace behind these objects.
Thatâs why itâs important for us to know what your actual real-world needs are, because it lets us balance these kinds of decisions.
I was thinking about what you show.
A kind of scanner/detector screen effect showing a character behind environment static props occluding him during the shot, while he moves.
And an NPR edge effect present in sharp reflections, and absent in stylised blurry reflections.
The first time, you mentioned collections for a workflow similar to light linking.
So, I only thought about the ease of use of a right click to include or exclude selection. But if it has a severe performance impact, that does not worth it.
In those cases, a Visibility toggle would be sufficient. A property state can be generalised to many objects, in other ways.
The following represents only myself. Itâs been nearly a month since there was any communication about this content. Of course, this might be considered normal for developers, but it should indicate some issues.
Feedback for feedback requests:
There are mainly two problems at present
The entry threshold for this node is not low, but it does not provide sufficient references.
This node requires not only sufficient experience in applying mathematical and geometric nodes (by default, users all have proficient experience in using geometric nodes and ray casting nodes), but also specific examples to prove it. It should be noted that this spans several fields including mathematics, programming, and fine arts
Perhaps this is a feature with unlimited prospects, but just like the mathematical operation node in the node tool is also a tool with unlimited possibilities, not everyone can start from scratch using the most basic tools. More people are non-computing field users such as art designers, and they hope to have easy-to-use tools.
However, just like geometric nodes, the target users of some basic tools are not the vast majority of ordinary people but asset and tool developers. Therefore, the priority considerations are functionality, long-term maintenance costs, etc. In contrast, it is a better approach for both users and developers to provide various easy-to-use solutions to ordinary users in the form of preset assets after the entire set of geometric nodes has a basic framework.
Similarly, as one of the fundamental tools of the NPR project, this node should indeed prioritize functional implementation and performance cost.
However, whether the official development can provide more application cases at this stage to lower the threshold and enable testers to see more possibilities accordingly, so far, apart from a few screenshots, I havenât seen any usage plans for this node (screenshots of how the node is used rather than the final effect) for reference or extension of ideas.
The development focus is biased
In terms of blender from the past to the present, NPR has long been reflected in eevee, and cycle is more about realistic rendering. Of course, for individuals, NPR is a broad concept. Similar to the more realistic NPR rendering in Disney Pixar, it is also NPR. But there is no doubt that blender eevee has a deeper accumulation of NPR (community sharing, user habits and experiences, etc.). If this node mainly focuses on eeve, it should receive more feedback.
Currently, the main performance of this node is in cycle, and its performance in eevee is just as previously reported - almost unusable (there are serious flaws in the quality performance based on screen space: various ghosting, black blocks of unknown origin, etc.).
Personally, I would rather sacrifice performance for high-quality performance. For NPR, the current mainstream approach is to render channel information and then perform subsequent rendering in post-production software, with the aim of achieving high-quality results. At this point, pursuing real-time rendering in eevee does not make much sense. And NPR gives such users the possibility to achieve the final effect in blender. So, can the performance of this node within eevee be of high quality?
Although it has been mentioned that there is a possibility of hardware ray tracing optimization in the future, no specific examples have been seen so far, and doubts remain regarding the current performance.
This node is a game changer for texture baking. Especially in combination with the Ray Portal BSDF. (1)
Curvature is the first thing that comes to mind, but you can bake anything through raycasts.
A normal output would be helpful of course.
As of now, even without the normal output:
It has similiar value as the RayCast Node in geometry nodes, where you can just sample freely without reliance on internal behaviours of i.e. bevel shader or AO shader nodes.
@1112 We will provide built-in node assets for common effects.
Those should also serve as a reference on how to use the node.
But yes, I agree that the node by itself may not be too intuitive for non technically oriented artists.
