Better software architecture?

[yczhang89]

Maybe taichi could be split into several modules:

1. (Module A) C++ graphics rendering engine: Given a 3D scene in a standard data format (e.g. the one in taichi/blender/exporter/__init__.py), the engine calculates a rasterised image. This rendering engine could be used interchangeably with other rendering engines.

2. (Module B) Python library to procedurally generate a 3D scene. The output is given in a standard data format, and can be fed into any graphics rendering engine.

3. (Module B) C++ physics simulation: given some parameters, calculates a series of scenes. This part could be integrated into Module B: this can be seen as a specific way to generate 3D scenes.

4. (Module C) A seperate Python library to handle realtime preview and program hot reloading, for any Python program that generates a series of images. We don't need to have lovecat integrated into Module C.

5. (Module D) A set of demos that is built upon Module B, Module C and lovecat. Binary asset files could go into Module D.

[yuanming-hu]

Hi Yucheng,

Thanks for your input and I feel sorry for the delayed reply. Not until recently do I get time to consider and do related engineering regarding general architecture.

The thing I worry about is that interchanging data as files onto disks may be much slower than doing so within RAM. I am not sure the ''standard'' data format for 3D scenes actually exists, and making exporter for each rendering engine can be troublesome.

Taichi can have its own format for 3D scenes. As the outer layer is wrapped with Python, it would be best to utilize some existing ways like pickle. I'm still considering if we also need a C++ wrapper. If so, we may not be able to use pickle, but another way to serialize/deserialize our data. I believe serialization would be necessary sooner or later, as when doing a simulation it is common that people want to stop halfway and restore the state afterward.

For the real-time previewer, currently I'm working on Pakua, a WebGL based visualization engine based on Three.js. Doing so removes the dependency on a game engine like Unity or Unreal and keeps installation of Taichi simple.

Regarding lovecat, I think it would be most useful for procedural generation, since much parameter tuning will be needed. Also, such generation can provide relatively fast feedback. (In contrast, rendering and simulation can be quite slow.)

[voronoipotato]

STL is a good format for geometry if you are going to make an export.

[yczhang89]

Sorry for the delayed reply.

The thing I worry about is that interchanging data as files onto disks may be much slower than doing so within RAM.

Adopting a standard data format doesn't imply that the data has to be written to a disk. You could still use RAM for data exchange. You may want to consider a RESTful API over network.

I believe serialization would be necessary sooner or later, as when doing a simulation it is common that people want to stop halfway and restore the state afterward.

Just a side note, what you need is actually serializing a continuation.

Regarding lovecat, I think it would be most useful for procedural generation, since much parameter tuning will be needed. Also, such generation can provide relatively fast feedback. (In contrast, rendering and simulation can be quite slow.)

lovecat is an alternative to the traditional node-graph approach, both of which has advantages and disadvantages. lovecat may serve your use case (producing a small demo for your new algorithm) better.

As for the realtime feedback, lovecat should have the same performance characteristics with node-graph. Note that caching intermediate results is also possible with lovecat.

However, unfortunately I currently don't have time for a Python-based lovecat.

[jawaff]

@yuanming-hu Hey, I saw that you mentioned Unity and Unreal. Do you know if there are any plugins that make this work with the Unreal Engine?

[yuanming-hu]

Hi @jawaff, the answer is no, for now...

[jawaff]

UE4 did some major interface changes and broke the nvidia plugins that do fluid dynamics not too long ago. You would be a hero if you brought fluid dynamics back into UE4, just saying.

…

On Wed, Jan 29, 2020 at 1:36 PM Yuanming Hu ***@***.***> wrote: Hi @jawaff <https://github.com/jawaff>, the answer is no, for now... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#27?email_source=notifications&email_token=AAWC3XHOAWUX5UYWVCQABITRAHZGXA5CNFSM4C5IRDM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKI2RCA#issuecomment-579971208>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWC3XCKV4H2RBELHCKVGP3RAHZGXANCNFSM4C5IRDMQ> .

[github-actions]

Warning: The issue has been out-of-update for 50 days, marking stale.