gifGeodesica-SFX Development Status

In the works: Geodesica-SFX-0-9-9-9m which features:

In the works: Geodesica-SFX 1.0 with multiple Undo/Redo, native Save/Open wmof files, parametric hybrid domes, and high-precision streams.

Development snapshots for MS-Windows 64 bit (Parametric Controller only):

Geodesica_SFX_WM4_OpenGL-1-0-0-19-dev-win64.zip
Md5 checksum:
F75B57C586A777E6716743A348D1B418
5.68 MB (5,964,363 bytes)
Uploaded on Fri Nov 20 2020 at 19:37 GMT
Readme
Changes.txt

The main drawback of dropping the legacy fixed function pipeline is that the program now requires a modern 64-bit computer with a high-spec graphics card.

As I expected, upating double-precision quad-edge geometry was much faster using the legacy fixed function pipeline: one could simply redraw the geometry between gl_begin and gl_end. In fact the “fixed” function pipeline was exceedingly flexible. The problem arises because the majority of OpenGL shader technologies use single precision float data for vertex buffers, whereas Geodesica-SFX uses double precision. (In fact, the new version of Geodesica-SFX uses long double precision). Thus when using modern OpenGL shaders, two copies of the geometry are required — one for double and another for float, (because double precision data cannot be cached on the card). The consequence is that whenever the geometry changes, all float-32 vertex buffers have to be deleted and recreated, each individual vertex being cast from a double to a float-32; these buffers are then re-cached on the card and re-attached to the scene graph. All of this involves expensive memory allocations, not to mention code bloat.

Update: Thu Sep 30 19:18:20 BST 2021

In order to get around the problems outlined above, I have opted to use a software renderer that takes long double geometry. This means the long double data type can be passed directly to the software shaders without casting to float-32, thus circumventing the need for two copies of geometry, (one in long double, and another in float-32). Another benefit of using a software renderer is that the program will run on any 64 bit computer. I expect to have a usable working version around Spring 2022. Development notes regarding a long double software renderer are documented here, along with a test program to download.

Geodesica-SFX 1.0 is a very different beast from the current version; the legacy fixed function pipeline has been dropped and most of the code has been re-written from the ground up, with multiple undo. The UI has also been completely overhauled. Rather than having a horizontal toolbar along the top, the main window now incorporates 'Controllers' which are located on the Left sash panel. The Log is intergral with the main window on the right; however both Log and Controller panels can be hidden by dragging the sashes to maximise the OpenGL view:

png

png png png png png

png png

There are controllers for Geodesic, Parametric and Particle spheres. Supported parameteric sphere types include Ribbed, Lamella, Schwedler and Diamatic:

png

The following three screenshots show a Lamella bullet; this was created with the same settings as above, except that y(u,v) = cos(v)*(t^2). The constant t was set via the button “Set Contants...”.

png png png

Below is a screenshot of the Module controller which allows for the creation of “Hybrid” domes. My initial idea was to automate the subdivision process for the quad-edge lattice; I then thought about providing an over-ride facility that targets each parallel row individually. This allows great flexibility when designing the structure. For example, the sphere below incorporates Lamella, Schwedler and Ribbed geometries. Parallels 1 to 8 exhibit Lamella subdivision; parallels 9 to 11 have Schwedler Left to Right subdivision, after which the Lamella subdivision recommences for paralles 12 to 14; this is followed by another Schwedler subdivision for paralles 15 to 17 (but this time going in the reverse direction); the final three parallels have a standard ribbed subdivision:

png

Below is a screenshot of the Sparse Zenith option as applied to a trifanned ribbed sphere. This option can only be used when the number of meridians is one of the following set: 4, 8, 16, 32, 64, 128. Thanks to Greg Robin of Triodetic Engineering who introduced me to this method of reducing crowding at the zenith. This option may be used with any parametric sphere type, including Hybrid spheres.

png

The following shows the difference in geometry using the Sparse Zenith option. This affords a considerable economy of struts whilst also improving the overall aesthetic of the dome. The still images show OFF and ON; the large gif animations superimpose OFF and ON to demonstrate the algorithm. (Note: gif animations do not play correcty in Internet Explorer 11 without applying an update from Microsoft - hence the inclusion of the still images).

1. Ribbed Sphere Sparse Zenith option:

png png

gif

2. Lamella Sphere Sparse Zenith option:

png png

gif

Below is the dual of a trifanned ribbed sphere onion dome. The Primal manifold is visible as the outer cyan wireframe. Don’t be fooled by what appear to be legacy GL_POLYGON faces. The blue dual edges are in fact a single non-contiguous, non-closed polyline, whilst each dual polygonal face is an individual trifan with its own material state. Drawing these individual trifans in direct mode using the legacy fixed function pipeline was much faster. However the frame rate is not really an issue when modelling or tumbling the view. Of course, I could assign a single material state to all trifans, but then colouring individual face groups would become a real headache. I am currently modifying the scene graph to support cell groupings at nodes rather than at the leaf, so this issue should be resolved.

png

As things stand, the user can select pre-defined parametric surfaces, or design their own using 'CUSTOM'. However, non-closed manifolds are almost impossible to support with the quad-edge data structure, so these might use standard meshes instead...

png png png png