Coding "normaly" and not data driven?

[erikpa1]

Hi guys (and ladies),

I have something about 5 years game experience in c++/python 3D VR and AR applications ( mostly VR training systems for companies, on private engine developed by my company), also some knowledge in Unity, UE and Godot, Nvidia Omniverse, coding in blender and many more. 1 year experience in THREE JS with React. I'm not flexing but I just want to introduce my problem from my point of view:

Can I code in normal 3D development pipeline?

Every framework I'm working on has same philosophy:

app = new App()
app.scene.add(new Cube())
app.scene.add(new Sphere())
app.scene.add(new Camera())
app.scene.add(new SomeLight())

app.ondraw = myfunction
app.onstep = myotherfunction

This example is specific for threejs, babylonjs and filament, ogre3d and many others, which is pretty easy to understand and when you work like this, its is easy to switch between technologies but when it comes to bevy or other rust engines its like hitting the wall. I'm always asking how to do this how this with this,... because is this data driven architecture is like switching from right hand to left hand for me.

Does anybody have same problem ? How did you solved? Did you just get used to this. Or you have some own way how wrap data driven architecture to non-data driven architecture?

Maybe some message for authors to think:

What you are doing is great, lets continue 🥇 I know you are maybe proud on your architecture and so on (I had this feeling many times),... but from my point of view this looks like engine from geeks for geeks. (as my linux fan friend used to say "I like the way how it sucks (or how its hard in this case)" ). When you want to create something beautiful you need graphics capable people instead of senior developers (like in this case). But I don't know what are your plans for future with this.

Here is some example from THREE Fiber here they have similar principe using react:

render() {
return (
  <Canvas>
    <ambientLight />
    <pointLight position={[10, 10, 10]} />
    <Box position={[-1.2, 0, 0]} />
    <Box position={[1.2, 0, 0]} />
  </Canvas>
)}

As you can see this is data driven architecture but this code get translated to code above, AND in some point of your code you can break this data driven and continue standard pipeline.

Thanks for advice, happy bevying. :)

[nicopap]

There are three major engine architectures paradigms in game dev:

• Inheritance-based (pygames, Godot)
• Component-based or ESC, which has nothing to do with ECS (Unity and Unreal)
• ECS, Entity Component System (some AAA games closed source engines)

Now, I would consider any of those paradigms "normal". What you are describing
as "normal" is rather "familiar to me". Each person is familiar with something
different, for example, Unity and Unreal devs would not agree that what you are
describing is the "normal 3D development pipeline."

From what you say you've done, by "normal", you probably mean
"inheritance-based". It is very unlikely that bevy will ever have an
inheritance-based API. Rust doesn't support inheritance, and inheritance-based
engines do not parallelize well (which is a primary goal of bevy).

Personally, I had no prior serious game dev experience before using bevy, so as
far as I'm concerned, the way bevy does things is the "normal" way. And I got
"used to it" pretty quickly.

Now to answer your question. I'll be honest, "Data-driven architecture" is very
misleading. The way you'd define a scene in bevy looks more
like your pseudo-code example than the TREE Fiber example. You just need to
know that what you call "scene" would be the game world, and the way to spawn
objects in the world is by using Commands::spawn.

Here is the bevy equivalent of your pseudo-code:

fn main() {
    let mut app = App::new();
    // This is a function that run once at initialization
    app.add_startup_system(setup);

    // `add_system` is equivalent to `onstep`
    app.add_system(move_sphere);
    app.add_system(move_cube);

    // need to run the app
    app.run();
}
fn setup(mut commands: Commands, meshes: ResMut<Assets<Mesh>>) {
    // `commands.spawn_bundle` is equivalent to `app.scene.add`
    commands
        .spawn_bundle(shape_bundle(shape::Cube::new(1.0).into(), &mut meshes))
        .insert(Cube);
    commands
        .spawn_bundle(shape_bundle(shape::Icosphere::default().into(), &mut meshes))
        .insert(Sphere);
    commands.spawn_bundle(point_light_bundle(4.0, 8.0, 4.0));
    commands.spawn_bundle(camera_bundle(-2.0, 2.5, 5.0));
}

#[derive(Component)]
struct Cube;

#[derive(Component)]
struct Sphere;

fn move_anything(input: Input<KeyCode>, mut to_move: Mut<Transform>) {
    if input.pressed(KeyCode::Up) {
        to_move.y += 0.1;
    }
    if input.pressed(KeyCode::Down) {
        to_move.y -= 0.1;
    }
    if input.pressed(KeyCode::Left) {
        to_move.z += 0.1;
    }
    if input.pressed(KeyCode::Right) {
        to_move.z -= 0.1;
    }
}
fn move_sphere(input: Res<Input<KeyCode>>, mut query: Query<&mut Transform, With<Sphere>>) {
    move_anything(input, query.single_mut());
}
fn move_cube(input: Res<Input<KeyCode>>, mut query: Query<&mut Transform, With<Cube>>) {
    move_anything(input, query.single_mut());
}

fn point_light_bundle(x: f32, y: f32, z: f32) -> impl Bundle {
    PointLightBundle {
        point_light: PointLight {
            intensity: 1500.0,
            shadows_enabled: true,
            ..default()
        },
        transform: Transform::from_xyz(x,y,z),
        ..default()
    }
}
fn camera_bundle(x: f32, y: f32, z: f32) -> impl Bundle {
    PerspectiveCameraBundle {
        transform: Transform::from_xyz(x,y,z).looking_at(Vec3::ZERO, Vec3::Y),
        ..default()
    }
}
fn shape_bundle(mesh: Mesh, assets: &mut ResMut<Assets<Mesh>>) -> impl Bundle {
    PbrBundle {
        mesh: assets.add(mesh),
        ..default()
    }
}

Bevy has no concept of "on_draw". It's handled by the rendering engine, which
you shouldn't worry about, unless you want to do very fancy stuff.

There is a way to define scenes similarly to your TREE Fiber in bevy, but this
only becomes relevant when you have complex scenes with lot of stuff (you
can imagine that defining scenes in rust can get pretty verbose.)

Check out the examples directory for example usage of bevy:

• https://github.com/bevyengine/bevy/tree/main/examples
• https://github.com/bevyengine/bevy/blob/main/examples/3d/3d_scene.rs

The cheat book is also a great way to learn bevy: https://bevy-cheatbook.github.io/

I encourage you to get familiar 😉 with the bevy ECS. I'll admit: ECS is
considered as one of the more difficult game architectures. But bevy is
probably the "easiest to use" ECS and it's always worth exploring new ways to
do things, it shades a new light to things you thought you knew well, and helps
you think more clearly about what you do.

Why do you want to use bevy? Are you here to learn? Well, I think bevy and rust
are a great way to learn new things!

I also want to point out that your post comes out as very haughty and
borderline insulting. Insinuating that community members are stuck in their way
and have no notion of what "normal" people do is rude. You'll have difficulties
finding people willing to discuss with you when you start by insulting them.

You probably didn't mean to be rude, but someone who wanted to be rude could
have done it the same way.

I hope this was helpful, and welcome to bevy!

[erikpa1]

Of course I wasn't saying nothing bad, I like every technology and I have respect for technology and its users (except c++ build system and external libraries linking (this is also reason I'm switching to rust) :D ). I have some projects in THREE JS I want to rewrite in rust bevy, because of performance. But rewriting this architectures between each other is really pain.

Really thank you for your example, maybe writing code in this way will make my migration easier.

Have a nice day.