0
Raytraced portals
Classic usecase. Basically, when a ray hits an object, this special material property would "teleport" the ray to another location, render layer, or scene. A simple UI would be to add a material output node with vectors "ray position" (or offset) and "ray direction" (or rotation), which represent to where the ray is transported after hitting the object. Obviously, this would only work in raytraced mode, and cannot work in paint rendering. Currently, this can be achieved using texture baking, but that doesn't lend itself very well to ambient occlusion or animation.

Login to comment

Comments(11)

lsscpp · 4 months ago (edited 4 months ago)

Can you please tell the benefits and use-cases of this?

Also a bit of mockup would be great

1 point reply
slugfiller [OP] · 4 months ago
Imagine a mirror, except instead of reflecting back the room in front of it, it reflects back a completely different room. Or a crystal ball that actually shows a scene inside. Or a wormhole that shows the other side, a-la the game Portal. You can add some refraction and to create a warped scene. Another use case is to create non-Euclidean scenes, by using portals to "fold space onto itself" in a way that simple mirrors can't achieve. This could probably be achieved with some inventive duplication, but bouncing rays around is simpler. As for a mock-up, if you mean the UI, it should probably look like any output in the material node editor. Although it depends on the way the renderer works and processes materials, so maybe it should be different. If you mean the rendered result, just take any screenshot from the game Portal, and you should have a general idea. Here, some examples: https://cdn2.mhpbooks.com/2013/07/portal.jpg https://upload.wikimedia.org/wikipedia/en/b/b7/QWRT_portals.png https://www.pcper.com/images/reviews/334/q3rt_cameraportal-small.jpg https://www.pcper.com/images/reviews/506/q3cameraPortal.jpg http://pcper.com/images/reviews/506/TwoCameraPortalsInPortals.jpg
0 points reply
Fweeb · 4 months ago
The difficulty here, as far as I can tell, is that none of the example images you reference actually use light from the other scene casting into the current scene. Furthermore, it seems like this effect could be trivially re-implemented or faked using existing capabilities and the use-case *seems* to be pretty uncommon. Sure, it would be pretty convenient if such a feature existed, but I'm not sure it'd necessarily be one of particularly high priority.. Of course, perhaps I'm just not seeing all of the other possible uses for this.
0 points reply
slugfiller [OP] · 4 months ago
The examples I've shown are from game engines, so obviously ambient occlusion doesn't factor into it. It's the obvious difference between real-time rendering and high quality rendering. I would like to know how this could be "re-implemented or faked using existing capabilities". As I've mentioned, texture-baking simply will not lend itself to animation, and would be a serious pain if you want to do portal-in-portal as some of the examples show. Manually duplicating the scene would not work for portals floating in mid-air (as a couple of the examples demonstrate), and could result in overlapping geometry even if you have portals on walls only. Quite frankly, I can't even begin to imagine how I would produce, using Blender, results that are identical to the images I've shown , let alone ones that fully leverages high-quality rendering (e.g. Putting a lamp on the other side of the portal, and having it cast a portal-shaped light on the outside).
0 points reply
Fweeb · 4 months ago
Ambient occlusion wouldn't factor in to this really, since what you're referring to is more of a global illumination phenomenon. Depending on the exact look you're trying to achieve, this can be done in a variety of ways. Animated textures, scene compositing, and (yes) clever lamp placement can all be used together to get the look you're aiming for. I'd personally probably opt for a compositing-based approach as it gives the most flexibiliity.
0 points reply
lsscpp · 4 months ago
Compositing is the way to go here. As far as the "infinite recursive camera" effect, i doubt that a portal could do that
0 points reply
slugfiller [OP] · 4 months ago
Here's an example scene, along with my best artist rendition of what it might look like rendered: https://pasteboard.co/f5kTVf8Lz.png The portal shows a nearby area, while also acting as a sole light source in that room, casting a spotlight, with a shaped shadow, on the floor. Secondary rays from the spotlight dimly illuminate the text and walls behind the portal. The other room, brightly lit, is visible from the portal (I didn't put much detail in it, but it could have more objects inside, like more text for example). Now show me how this can be achieved convincingly using compositing (My own artist rendition is anything but convincing, and required manually drawing the shadow). This is trivial for a raytracing renderer like Cycles, if ray teleportation is allowed. "Infinite recursive camera" is also equally trivial, since it's simply a matter of calculating more ray bounces (Up to some limit/distance). It's trivial enough for realtime engines to do it without any special tricks.
0 points reply
lsscpp · 4 months ago
Ok, I still don't understand. You say it's trivial, but since you're sponsoring a proposal, could you tell how it can be obtained? for example, in your picture how can the renderer know the "portal input?"
1 point reply
slugfiller [OP] · 4 months ago
The circular face has a nodes material. One of the outputs is a vector indicating how much to shift a ray. In the scene I've described, this could be a constant indicating that the ray should be moved 10 units in the X axis (constant vector (10, 0, 0)). When a ray (for instance, coming from the camera, or bounced off of the floor) hits the portal object (the circular face in front of "behind"), it detects the nodes material, derives the offset, and recasts the ray from the offset position. This causes it to intersect with the other room (e.g. the "Inside" text). Beyond that, the rest is just normal global illumination stuff. e.g. Tracing rays from the floor towards the portal to detect the light source on the other side. This is something that Cycles already does, and even with the current algorithms it uses, the result should be "good enough" (at least with enough iterations/rays). It's no different from how it has to deal with reflection and refraction. Obviously, the way I'm describing can ONLY work in raytrace, and not in raster. This is intended as a raytrace-only effect. Is it clearer now?
0 points reply
lsscpp · 4 months ago (edited 4 months ago)

yes indeed, now i see how: vectors!
I think that referring to a target object would simplify everything though. Otherwise it would be hard to precisely shift/rotate vector using just number

0 points reply
slugfiller [OP] · 4 months ago
I've considered object->object. For simple use cases, it saves the artist some effort, although it simply shifts that effort onto the program. The requirements for objects "matching" each other could be problematic. What more, the material nodes editor doesn't have too many nodes that allow you to select another object, so it might be going against the renderer architecture as well. I'm trying to take what is possible in the program currently into consideration. Besides, it would limit more "inventive" uses of ray teleportation, such as non-linear transformations, or causing rays from multiple angles to "focus" into a narrower beam, etc etc.
0 points reply
ChameleonScales · 4 months ago
Not the most flexible but you can do this (go in render mode) : https://www.dropbox.com/s/k7frjr7l4fp838a/portal.blend?dl=0
0 points reply
slugfiller [OP] · 4 months ago
The no-image no-reflection trick. I've seen it done in POVray. It's nice, but fails if you want multiple portals, or to have shadows cast through the portal. I'll admit that it's useful for simpler scenes.
0 points reply
Choose a category
Upload an image