Introduction

There is a clear distinction between the core of the software (which is responsible for selection handling, tweaking, rendering, user interaction) and every other modeling-related functionality. While the core is a small and fast C++ multithreaded engine, every modeling tool is a Python function (or a collection of functions) invoked by the user. When the user double clicks on an edge, Glise calls the Python function responsible for selecting edge loops, which in turn relies on the fast selection handling provided by the core.

Programming Glise is the philosophy at the heart of its design.

Every modeling feature is imported at startup from a tiny, precompiled Python module: the pack. This file provides everything, from face extrusion to edge connections, from polygon creation to normal flipping. This modularity in design also means that every bug-fix, tool, file importer or feature change can be easily applied by simply downloading the latest pack.

Programming Model

In order not to force the developer to use specific math libraries, vectors are represented as 3 elements standard lists. No specific vector math functions are defined, the developer is free to use whichever library he/she thinks may best match his/her specific needs, or write them from scratch.

Every topology change is achieved exclusively by face destruction and/or (re)construction. If you think this may lead to slow performances, think twice. Glise is highly optimized for frequent, repeated simple tasks like this. From this simple architecture any developer can build specialized functions for connecting vertices, splitting edges, flipping normals and the like.

Python execution seamlessly integrates with the undo/redo subsystems. When control returns from Python to the main pipeline, the current selection, if not empty, will be appended to the selection undo queue, and any tweaking or topological change occurred during Python execution will be stored in the topology/tweaking undo queue as a single unique block. This means that performing an undo (on any queue) restores the scene or selection as it was before Python code invocation, regardless of how many tweakings, topological changes or selections occurred during its execution.

In order to let the developer choose if and when to implement symmetry, Glise will not automatically perform any symmetrical operation during Python code execution. It is up to the developer to use the provided methods and properties to correctly handle symmetry.

Note that symmetry map evaluation always occurs after control returns from Python code execution.

Functions can work together, injected in the main pipeline as mouse events callbacks, and called upon user interaction. This allows for tool development, since tools, unlike single-execution actions, may interact with the user and/or change behavior during their own execution.

Ready?

This is an API reference, not a tutorial. We will write many, meanwhile you should get all the information you need from this material. However, shall you need more help, feel free to contact us at suppo.nosp@m.rt@t.nosp@m.wiste.nosp@m.dnor.nosp@m.mal.c.nosp@m.om

Have fun!