TDisk2DNode again

1

Well, almost there but not quite :smiley:

I wanted to put a really large disk over the square viewport as a vignette (so, .InnerRadius is half the width), and… it is edgy! :smiley:

function TCircle2DNode.CalculateSlices: Cardinal;
begin
  // use default in case of -1 or invalid value
  if FdSlices.Value < MinTriangulationSlices then
    Result := DefaultTriangulationSlices
  else
    Result := FdSlices.Value;
end;

but

function TDisk2DNode.CalculateSlices: Cardinal;
begin
  Result := DefaultTriangulationSlices;
end;

I blissfully ignored the “Do not edit this file manually!” warning and just copypasted it anyway :smiley:

Seems working okay, but i won’t be proud of it :smiley:

…also, why strict private is function CalculateSlices: Cardinal; ?

Seems a handy way to calculate effective value. Why not public?

Then the DefaultTriangulationSlices forwards users to Geometry3D component - extensions | Castle Game Engine but…

Ahem, it does not link back to TAbstractGeometryNode and friends (at least those few who do have FdSlices) .

Making use of that information is not obvious…

2

Once again i feel like it would be nice if those low-level components could reach back to the ViewPort and the physical screen properties, to asses their size in pixels and dynamically adjust slices quantity…

3

Sure, implemented Disk2D.Slices property.

Trivial test in X3D here: demo-models/2d/2d_geometry_nodes.x3dv at master · castle-engine/demo-models · GitHub

Screenshot here: demo-models/2d/2d_geometry_nodes.x3dv_screenshot.png at master · castle-engine/demo-models · GitHub

Because I didn’t see much need for it. Everything we make public is then a burden to maintain. As time goes by, I am more and more careful about exposing things public without a really convincing reason :slight_smile:

In case of this particular method, it’s not really a big deal to expose it, it’s a trivial method. But then it’s also not a big deal for particular need to just implement the same logic on your side. We don’t plan to change the logic of this subdivision any time soon.

Thanks, these docs contained a few outdated things (we don’t have divisions on Box anymore, we don’t have any “over-triangulation” since a long time because we don’t even use Gouraud by default). I improved them and linked.

I wondered about this in the past, both for simple primitives (like spheres or circles) and also for NURBS (to adjust tesselation). It is tempting, and with modern GPUs and geometry shaders it could be really done dynamically and efficiently.

… But the use-case seemed rather low, compared to the additional code complication. And on some really ancient GPUs, there are no geometry shader nodes. It seemed much easier to just allow user code to set higher DefaultTriangulationSlices / DefaultTriangulationStacks when neeeded.

Most 3D rendering is just using meshes (sometimes with LOD), as they are much more flexible to express anything (which is e.g. why glTF doesn’t even define any primitives or NURBS; only meshes). So the logic of “automatically adjusting primitives / NURBS to screen” would be a significant effort to implement, and mostly unused in many practical games.