[0] https://opentk.net/

[0] https://en.wikipedia.org/wiki/Lightyear_0

React Native uses Skia under the hood as far as I recall.

Comments URL: https://news.ycombinator.com/item?id=46759529

Points: 2

# Comments: 2

Here’s a quad tree:

11

11

—

0110

0110

1111

0110

—

00000000

00011000

00011000

00111100

01111110

11111111

00011000

00011000

I’d also love to be pointed to other techniques or approaches that might be better.

Let me know if the part about recording the diff is of interest.

Comments URL: https://news.ycombinator.com/item?id=44947686

Points: 2

# Comments: 1

Take this example: "When debugging I typically:"

> Write tests to isolate the problem

In the case of math functions, or more primitive building blocks, writing tests can help ensure correctness of the underlying functions, to exclude them from the problem search.

> Reason about the code logically first

This is always useful.

> Use a debugger to step through code systematically

Useful when dealing with a larger codebase and the control flow is hard to follow. The call stack can give quick guidance over trying to manually decipher the control flow.

> Add print statements to understand data flow:

Useful when debugging continuous data streams or events, e.g. mouse input, where you don't want to interrupt the user interaction that needs to be debugged.

I tried uMake a while back, but found the 3D viewport navigation a bit hard to use, and would often find out I had been drawing on the wrong plane after orbiting the camera.

After using something like Tilt Brush in VR, it's hard to go back to a 2D screen that doesn't instantly communicate the 3D location of the brush strokes you're placing.

I'm definitely aiming to build a more focused app compared Blender, as I want to focus explicitly on modeling, e.g. BRep or NURBs.

What kind of apps have you worked on?

I think I'm going to focus more on CAD / architectural use cases, instead of attempting feature parity with Blender's main selling points (rendering, hard-surface modeling, sculpting).

Getting fully featured Blender on the iPad will be amazing for things like Grease Pencil (drawing in 3D) or texture painting, but on the other hand my side-project just became a little bit less relevant.

I'll have to take a look at whether I can make some contributions to Blender.

[0] https://apps.apple.com/nl/app/shapereality-3d-modeling/id674...

Game engines and other large codebases with graphics logic are commonly written in C++, and only having to learn and write a single language is great.

Right now, shaders -- if not working with an off-the-shelf graphics abstraction -- are kind of annoying to work with. Cross-compiling to GLSL, HLSL and Metal Shading Language is cumbersome. Almost all game engines create their own shading language and code generate / compile that to the respective shading languages for specific platforms.

This situation could be improved if GPUs were more standardized and didn't have proprietary instruction sets. Similar to how CPUs mainly have x86_64 and ARM64 as the dominant instruction sets.

Metal Shading Language for example uses a subset of C++, and HLSL and GLSL are C-like languages.

In my view, it is nice to have an equivalent syntax and language for both CPU and GPU code, even though you still want to write simple code for GPU compute kernels and shaders.