Separate Front-end and Back-end

[MilkBlock]

Separate Front-end and Back-end.

Use Egglog and a suit of Predefined Ranim Egglog Type to separate Front-end and Back-end to support interactive mode.

The procedure is like:

1. Guest send Ranim DSL to Host
2. Host interpret the DSL to Rabject
3. when Rabject on Host is triggered (clicked dragged...) call Guest defined Function
4. Guest send incremental Ranim DSL to Host to update the rendered Rabject

And the situation can be more complex when touching persistence (undo some operation).
Luckily we can deal with it easily with egglog (similar to persistent database which minimize the memory occupation).

I wrote a proc-macro lib by which you can easily define a suit of Predefined Ranim Egglog Type by #[egglog_ty] attribute.

#[allow(unused)]
#[egglog_ty]
enum Fn {
    Builtin {
        function: BuiltinF,
    },
    WasmGuestExtern {
        name: String,
    },
}

Ref:
https://github.com/MilkBlock/egglog_wrap_test/blob/master/crates/egglog_wrapper/src/lib.rs

And you can simply call such generated function to generate egglog statemnt in String.

let p = Point::<Rx>::new_fixed_point(&Offset::new_d_vec2(1.0, 0.));

while the Rx type specifiy a Receiver (Host). It will automatically call user defined receive function.

All code that user need write is here.

fn main() {
    let p1 = Point::<Rx>::new_fixed_point(&Offset::new_d_vec2(1.0, 0.));
    let p2 = Point::new_fixed_point(&Offset::new_d_vec2(1.0, 2.));
    let ps = Points::new(vec![&p1,&p2]);
    Rx::singleton().to_dot(PathBuf::from("egraph"));
}

which also enable users to inspect the graph they generated.
https://github.com/MilkBlock/egglog_wrap_test/blob/master/src/main.rs

[AzurIce]

I think I'm not planned to adopt any DSL, or do frontend backend separating base on DSL.

DSL is far more less expressive than a genreal purpose language. It is all about "specifying something fixed" like content, layout, relation, rules, etc. These things are not plenty to building an animation we expected to build with a programmatic animation engine, and will definitly involve a general purpose language. HTML, CSS and JavaScript is an example.

Instead, the architecture in my mind may more likely to achive this through language binding stuffs. For example, ranim offers the basic primitives, and build all items based on those primitives, and provide different language bindings to make other language to be able to use ranim's types. Then do interop through something like FFI or runtime/interpreter. Just like a game engine.

A very good example is rerun, it uses protobuf to transfer primitive data in between languages/apps. May be ranim can do something simular to transfer primitives, but logic is hard to be serialized, so maybe the eval part will happen on the script language side, and do the rendering in ranim rust side.

It is still very far to implement these stuffs. Currently ranim will focus on the native rust experience. Once it is stable enough, we may start implementing these stuffs.

[MilkBlock]

DSL is far more less expressive than a genreal purpose language. It is all about "specifying something fixed" like content, layout, relation, rules, etc. these things are not plenty to building an animation we expected to build with a programmatic animation engine, and will definitly involve a general purpose language. HMTL, CSS and JavaScript is an example.

As for general purpose language, I think this is a good example grabapl.
Protobuf may not be suitable, it is better to transform WebAssembly in my opinion.

This example still lacks some important feature to be general (such as timeline info and event system) but it shows a way to wrap computation into WebAssembly.

And my hope for the DSL is to implement a runtime trait system as runtime trait.

I think it may be possible to merge them into one idea. We can directly do revision on grabapl to suit our needs.

What do you think of this? @AzurIce

[AzurIce]

Protobuf may not be suitable, it is better to transform WebAssembly in my opinion.

The requirement of "transferring sth" is for making a "bridge", in the senario of separate frontend and backend, this "bridge" is for attaching user's code and the engine runtime, also if they are different language, the bridge also bridges languages.

And what user's code does, in a programmatic animation engine, is defining entities and a process around them for the runtime.

There are two scenarios depending on the programming language used in the user's code：

• Compiled language
  We can directly compile and link user's code and engine runtime together(The basic usage of ranim crate).
  We can also dynamically load dylib of user's code(Current ranim-cli's approach).

• Interpreted language
  We can embed an interpreter in engine runtime, and map the operations.

The above lines are methods of bridging user's code and the engine runtime, for different language we'll also need language binding to provide same types to different language, maybe by using c-ffi or something.

By shipping user's code or its compiled artifact, entities and their process can all be well transfered.

Or another solution (like by protobuf), is basically doing multi process programming(just like rerun). But it cannot transfer "process" well only through protobuf, so the architecture maybe will need some change, to make the eval part happends on users code (but this is not what I expect).

And my hope for the DSL is to implement a runtime trait system as runtime trait.

I don't think a runtime trait system has its necessity, an ECS architecture may be just enough to represent all things we want. Actually I'm thinking about adopting an ECS architecture, but I need a long time to think about it.

And at the same time, doing such things to enable multi language support will expose many things as an outer api, however the architecture and the main api design are not really stable now, many things still have breaking changes frequently, so this issue is not prioritized for now.

[MilkBlock]

This discussion is beneficial. I think we can split the whole picture into 2 levels.

Level 1: Ranim Bare Engine, parsing the bare input(timeline & elements) then render it in 2 ways (online & offline)
Level 2: Ranim Higher Abstraction, aiming to provide an ECS system for user to specify the render & update Logic .

The problem is that we have to think about the decoupling of Level1 and Level2. This is a hard thing, because animation is something changing all the time. It breaks down and combines into other things, so in this comment I talk about auto-maintenance. Leave that decoupling to next comment.

As for my use case, I want to Ranim to be Animated UI. That means I should define visualization hierarchy, click priority(unit overlap), input event, UI layout. Allow user to load or unload component in runtime.

Traditional ECS framework hates frequently appending or deleting components, if you read bevy you will find you have to move whole column though you only want to add a component, which cause low performance.

While System has same problem, system is designed to something flat, for example gravity calculation system for Transform component. In Gravity case, it's powerful because the calculation is physically orthogonal. It suits additivity well.

If you want to do UI things ECS will say "Oh sorry, you'd better not to visit so many components", we all know if you move one Button, then adjacent buttons should move at the same time to prevent overlap to make the whole layout clean.

For example in iPad UI, if you want to remove one App from home, you can just stick to one App for few seconds and then you can freely drag the App Icon and leave it in trash bin.

To implement this feature I should inform all the App icon entities "you can move freely according to user selected App's position". So I should apply a system on all the transform component. But that's not enough, I should also add a selectedbyuser marker to the selected App icon and insert the selected component to user entity. I personally call these marker component additivity maintenance component pair. You have to manually maintain both Selected component and SelectedBy component.

And that's why Bevy provides relation to process them. relation is a kind of micro runtime trait system automatically maintain SelectingBy and Selecting relation. Once you remove Selecting component the SelectingBy component should be remove automatically.

In my imagination of Animated UI framework, Auto-maintenance should be easy to define, not only providing Select such fixed and simple semantic. Just like the comparison between traditional edge and hyper edge in discrete math.

For example, we have one rules:

enable Perpendicular trait(line1, line2) -> enable Visible trait(Label("this is perpendicular! "))

That means if user interact with Animated UI to let line1 be perpendicular to line2 then show the label.

This is a simple situation and let's consider more. How can we describe the pull rod interaction?(pull rod can only be dragged to angle between 0 degrees to 180 degrees)

enable GreaterThen_180_degree trait(rod) -> enable ForwardDragging trait (rod)  + disable BackwardDragging trait (rod)
enable LessThen_0_degree trait(rod) -> enable BackwardDragging trait (rod) + disableForwardDragging trait(rod)

Auto-maintenance is everywhere in the world, that's why I think a runtime trait system essential.

That means I should apply a rule-based framework to infer the chemical reaction when events mixed up to do random things to components. Flat components are not expressive enough to undertake the job, we should append some relation/trait as seasoning.