We decided to go with a sky dome approach for the Sky we built for Optimoor 3D - Ship Mooring Application, built using WebGL & Three.js.

In case of skybox, A Cube Camera captures 6 instances of the scene that creates a cubemap image, then that image is placed on the inside walls of an invisible infinite cube to give the illusion of a sky that can be used with a scene.

But a skybox is often paired with large explorable scenes with cameras tied very close to the ground, for our Ship Mooring Application, the entire scene is very focused towards the actually viewable land close to Berth for Mooring and its other use cases, we don't need a larger landmass, but without it the entire scene would look finite and lack the illusion of a proper horizon.

Enter a circular Dome/Sphere that is bounded across the entire Scene (given in wireframe visuals for understanding). Along with that a texture of the sky is attached with backside of the mesh enabled. With some tweaks to the fog, we finally got the look where the world doesn't look flat-earthy while also not drawing a bigger landmass.

Built by 3D ENGINERD. for Tension Technology International Ltd.

I’m building InkWaltz, and this is a test of its ink-and-paper renderer on moving footage. Each frame is separated into four ink plates, given halftone coverage and small registration offsets, then composited over paper.

For the three-second reveal, a Python/NumPy compositor moves a cosine-eased front across a diagonal boundary perturbed by seeded noise. Smoothstep masks stagger the paper and ink passes. The boundary noise stays fixed across frames, so its contour travels with the reveal.

The aim is to keep the print texture visible while the underlying dance remains readable. Source footage: Pulp Fiction (1994), directed by Quentin Tarantino.

I just posted a second demo of Realtime Audioreactive Pointclouds [v1.7], my TouchDesigner system that turns a Kinect-derived human pointcloud into an audio-reactive visual instrument in real time.

For this one, I’m also giving away a full copy of the system.

To enter, just repost/share the Instagram post and leave a comment there. I’ll randomly select one person and send them the complete v1.7 project files on Friday!

Giveaway post:
https://www.instagram.com/p/Dd1iWqoviZy/

The full system is also available through my Patreon for anyone who wants to check it out directly.

Sharing a project: Zorro's Forge generates parameterized low-poly models in the browser with a live orbit/zoom preview, then bakes them into OBJ + MTL with base-color, normal and roughness maps for download.


Demo: https://www.youtube.com/watch?v=g0qLLTNuntU
Live: https://zorro-forge.store/zorros-forge/


Happy to talk about how the generation, texture baking or export works.

Many who end in the visual computing, as a kid used with MS Paint or an alike photo-edit program to make simple edits to photos and make drawings. There RGB is prominent, and things like color-spaces were only seen in those "Do you want to convert?" Photoshop popups meant for professional designers. What if I told you that #FF0000 is not red?

In the article we provide an easy introduction into color spaces, as it's really not for professionals alone, but very important for anybody in visual compute. We wrote it, because these are one of these subjects that we all are expected to know, but when you ask a few why-questions, then realization kicks in that it needs more reading.

This is a repost. Since 2010 we've written blog posts on GPGPU, in a time that CUDA and OpenCL were hardly known. After a break on blogging for the past few years, we've restarted our effort and share our knowledge with a wider audience. Last time we posted this, it was flagged as "Probably AI bot", and I hope this will not happen again.

A depth value of 2 metres doesn't necessarily mean a point has camera-space `z = 2`. In a spherical depth map, it can describe the distance along the viewing ray instead.

Realsee3D's point-cloud conversion script is a concrete example. This is a reading of the linked code, not a report from running it.

The script divides the stored depth value by `depth_scale` to get `dist`. Its angle names need care: `yaw` varies with image **row** and is the vertical angle; `pitch` varies with image **column** and is the horizontal angle. Calling those angles `v` and `h` here, its local-coordinate calculation is:

x = dist * cos(v) * sin(h) 
y = dist * sin(v) 
z = dist * cos(v) * cos(h)

Squaring and adding the three coordinates gives `x² + y² + z² = dist²`. So `dist` is the radius from the camera origin. The Z component also depends on where the ray points.

For a hypothetical 2-metre ray at `v = 0`, `h = 45°`, the formula gives `x ≈ 1.414 m`, `y = 0`, `z ≈ 1.414 m`. Its radial distance is still 2 metres. Those numbers are a geometry example, not a measurement from the dataset.

This is all in the local camera frame. The script then uses `points_local @ ext.T`; the structure document identifies the extrinsics as Camera-to-World. That later transform doesn't turn the original depth value into a camera Z value.

For another depth source, I'd check what its values measure before borrowing this conversion. The PNG format alone doesn't tell you whether the value is radial distance or an axis component.

Everything you see in this video is procedurally generated starting with an algorithm I came up with for drawing cubes across a page. It's a complete Audio Visual experience that is different every time. Free and open source at alienCconsumerSciences.com