The Zetane Python API functions as the coordinator between your python scripts and the Zetane engine. This is done via the zetane context, which manages connections to the engine and handles data synchronization and queueing. From the context object, individual objects are generated and used by positioning them within the 3D environment.
import zetane.context as ztn # creates a context and launch the Zetane engine zcontext = ztn.Context()
After creating a scene and launching the engine, we create objects inside of the scene which will be driven by data from our python script.
model = zcontext.model() text = zcontext.text() image = zcontext.image() graph = zcontext.chart() metric1 = graph.metric() metric2 = graph.metric()
All of these objects inherit from a base class called zobj which implements functions that position objects inside of the 3d scene. For example, position, rotation, and scaling:
image.position(0.0, 1.0, 0.0).rotation(1.0, 0.0, 0.0).update()
All calls are chained in the API, with the final
update() call used to synchronize data with the engine itself.
To disconnect from the engine while keeping the Zetane window open, call:
To close the Zetane window instead (and disconnect from it), call:
The following classes are all instantiated via the context object (factory), despite being able to be constructed as objects, the context object sets the proper socket to connect to the Zetane engine.
All objects implement a debugging call where you can stop the execution of the python script in order to explore the environment. You can do this by chaining a
.debug() call on any method that returns the object / primitive. The general pattern in the Zetane API is that every method returns
self , so all methods should be chainable in this way, e.g.
Debugging performs an
.update() internally, so calling
zmodel.keras(model).inputs(inputs.cpu().numpy()).debug() works in the same way.