Maybe adopt (or document) a quil-like workflow of setup, update, draw functions

[joinr]

As I look at more examples, I think this is already there. It was not obvious to me that the output of render actually provides the context so that you can mess with it (adjust the camera, renderer, etc). This is akin to setup in quil (setup-scene in the tetris demo kind of gets at it https://github.com/DougHamil/threeagent-examples/blob/master/tetris/src/main/tetris/app.cljs#L72). The draw call is already there in the api more or less. I think draw/update are sort of interwoven at the moment (it seems like draw is expected to perform any updates like ticking prior to rendering). This might form a familiar model for folks coming in without three.js background, but conceptually understanding the concept of a sketch.

I am also looking at a simpler, pseudo-synchronous way to handle assets (fonts, textures, models, etc.). Basically have the setup logic load everything that's needed, then have the draw function able to make the assumption that everything is accessible from the state. It would preclude the potential mishmash of resource checks like the one for text's dependency on font presence in https://github.com/DougHamil/threeagent-examples/blob/master/tetris/src/main/tetris/app.cljs#L27

[DougHamil]

It was not obvious to me that the output of render actually provides the context so that you can mess with it (adjust the camera, renderer, etc).

Good point. I actually will be changing the return value of threeagent.core/render to return a clj map:

{:threejs-scene scene
 :threejs-renderer renderer
 :canvas canvas-dom-element}

The current object that is returned leaks an implementation structure that I don't want to support in the public API going forward. At this point, I'm not sure about returning the camera instance, as that really should be defined in the user's scene-graph and the default one is just for convenience.

The draw call is already there in the api more or less. I think draw/update are sort of interwoven at the moment (it seems like draw is expected to perform any updates like ticking prior to rendering). This might form a familiar model for folks coming in without three.js background, but conceptually understanding the concept of a sketch.

This is an interesting idea. The current render function mimics Reagent's API. A Quil-like API could be built on top of it pretty easily and it wouldn't need access to the Threeagent internals. And, yes, Quil's draw function wouldn't really make sense, but there could be a tick or update option.

I am also looking at a simpler, pseudo-synchronous way to handle assets (fonts, textures, models, etc.).

I have also been working on something similar! My current approach is like a mash-up of Reitit and Integrant, where assets are broken down by their paths, you can apply middleware for processing assets, and you can define references to other assets. It will then convert this tree into a dependency graph of Promises and resolve them.

Currently, I wasn't thinking of building this into Threeagent. I want to keep Threeagent fairly limited in scope, and asset loading can be pretty easily isolated from Threeagent.

It would preclude the potential mishmash of resource checks like the one for text's dependency on font presence in https://github.com/DougHamil/threeagent-examples/blob/master/tetris/src/main/tetris/app.cljs#L27

Yeah, this was definitely experimental and I would highly recommend not following that approach and instead loading all assets up-front.

:smile: Sorry for the wall of text, but you're hitting on all of the things I've been exploring recently, which is great!

Ultimately, I was thinking of creating a separate library that uses Threeagent, but provides functionality useful for making games. This would include asset loading, built-in systems for physics, interactions, sound, etc. Maybe a similar approach could be taken for creating sketches instead of games.