What means roof:direction=E ? Really East? #OSM2World "snaps" to the next wall angle. (pic 2) #F4map produces a bit of a disaster (pic1)
We should try to make an own rendere, "like F4" but better. And we try. (pic3/4) A lot to code, a lot to analyse and describe, how to make #OpenStreetMap tagging to a 3D view.
Would you like to help? Just Testing? Documentation?
Do you code #Bevy #BevyEngine? Do you know #GPU coding? UI design? #wasm ?
Yes, Urban Eye 3D is “the new kid in town”. Really great to see live changes of JOSM edits. It lacks some features but as it is integrating code from OSM2World, it will bekomme a full Building viewer. But it can’t run stand alone and aims not to become a full world viewer.
OSM2World could be …
https://community.openstreetmap.org/t/roof-direction-e-a-better-f4map/134440/3
@rust_osm_tb thank you. looking through it, you seem to be using bevy mainly for rendering generated meshes. i was really hoping you'd have imported the OSM data into the ECS and were building a mesh from that... because thats how i would attempt this, as the ECS is arguably the biggest way bevy makes code structure easier
is that mostly because you seem to have switched from rend3d? Or do you want to keep the mesh generation separate?
@laund That‘s interesting. I do not understand Bevy that well. May be you could explain what you expected and how I could implementiert it.
Yes, the crate/lib should work not only with Bevy but also with different renderer. Rend3 was just used to prove this! Did you see the WASM example? It uses the Bevy Asset-Loader, but only because I did not find a way to load async with WASM.
The ECS is good vor games and For populating the Virtual world with cars. I will add examples games later.
@laund Hey @laund , I am still thinking about my code for #BevyEngine and #ECS . Would you be so nice and give me some hints about what you have in mind?
I may have an idea: I use #RustLanguage in the sense of #ObjectOrientation. But I could use ECS resources instead. For the " #classes " Node, Way/Area, Relation and for FootPrint, Buildings. That could speed up my code as it may run multicore this way.
The sources osm2layers, ... could get converted to an ECS version.
May I ask you about Bevy?
@rust_osm_tb you're thinking in the right direction. In ECS, you have entities which are defined by a collection of components. This maps pretty well to how osm works woth tags.
youd have components for the types of features like Node and Way, but also a component for each tag, where the tag key is the struct name anf the tag value is its value.
Relations can also be components, but bevy has custom relationships built in, so it would make sense to have Relation be a custom bevy relationship.
You'd then want to also split your logic into individual systems which each only deal with a small subset of components. Bevy also has event handlers and hooks, so you could attach logic which handles specific components being added to an entity.
@laund Sounds promising. I need to dive deeper into ECS. Handle even Tags with ECS makes me worry, if the ECS will need more time but now.
Do you think, my use of the Asset Manager and the Deserialisations are ok as it is now?
I think, I will start with "osm2layers.rs" as an experiment at last. Would you like to get access to my repository? You could even show me your solutions or change my mistakes. We could start with "fn add_node". Or would you even have an idea vor "scan_json_to_osm"?
@rust_osm_tb bevy has an asset system built in, which you can extend through custom sources and loaders, but that's probably not necessary.
For tags, i was assuming there is a limited subset you're interested in for this project, i definitely wouldn't store every tag as its own component.
having them as separate components allows queries to work on them, as bevy cannot query by value, only by type. So you want at least the tags which you might want to query on (for example, writing a system for all houses with certain roof tags) as components.
@laund Did you see my code? I do use custom assets. Or do you know another way to access the OSM API and de-serialise Json? And I can't find a way to catch the 404 Error to show a "Way does not exist" message. Could you help?
Yes, only about 20 Tags are relevant, for now. Just for curiosity I would try it the ECS way.
Such thing as "houses with roof" means thinking backward to me. Default is flat, so all houses have a roof, a footprint, ...
Are you only in ECS or all Bevy?
@rust_osm_tb Ah, i hadn't checked the examples, as usually you'd implement an asset loader in the library and then just call the asset loader from users of the library.
Your systems can get asset load errors through AssetServer::get_load_state(handle) which includes an error variant. I dont recall exactly how you set the error to something custom, i think its just by returning it from your asset loader load method. I think you'd want to check the load state when recieving asset events but i don't know which event is sent upon error.
@rust_osm_tb looking at your AssetLoader, it seems to just load bytes. Generally, an AssetLoader should do the actual work of loading an asset (parsing json, constructing components), but yours seems to just return the bytes directly.
For comparison, have a look at the struct returned by bevys GLTF loader: https://docs.rs/bevy_gltf/0.16.1/src/bevy_gltf/assets.rs.html#17-48
As you cna see, it returns meshes, materials etc. ready to spawn an entity with them. Ofc this is a relatively complex cas, but it shows nicely what i mean. In your case, the step 1 and step 2 from the on_load function seems like it should be handled by the asset loader, possibly with asset dependencies. (a OsmBbox asset loads all buildings inside it, for example). The way to do this is with the LoadContext: https://docs.rs/bevy/latest/bevy/asset/struct.LoadContext.html
you can use this to load further assets as bytes (for further processing) or as a handle (for things that have their own loader, like images). The reason bevy asset loaders are async is partly because they give you the option to do this, load other assets, without an awkward "load the first thing, listen for an event of it being loaded, then load the second thing" - you just .await the loading of the inner asset.
you can also use the context to add sub-assets, in case a single asset load gets you the data for multiple things, like an API request returning many buildings.
I highly recommend trying to at least loossly grasp the way the gltf loader is set up, its the most complete example of a complex multi-step asset loader we have.
one thing an asset loader can't do directly is spawning entities, which is why the gltf asset loader is used like this: SceneRoot(asset_server.load("scene.gltf")) - SceneRoot handles the logic of spawning entities from the Gltf asset. You might want a similar thing which wraps the asset as a component and is responsible for spawning the other entities.
@rust_osm_tb as for "thinking backwards" - its likely i was just wrong due to my lack of understanding of this specific subset of osm tagging, but its similarly likely that it will feel backwards for a bit till it clicks. ECS is a really different way of working when you're coming from OOP. Its a relatively pure expression of "composition over inheritance" - the main thing which determines what kind of entity you have is the set of components it has. "Entity" is just a integer index, like a DB table primary key.
I basically started learning Rust through Bevy, and haven't done much which wasn't related to bevy at all, so you could say i'm all Bevy. But i'm not sure what you're actually asking. Is it about bevy-specific knowledge vs general ECS knowledge?
@rust_osm_tb For wasm, you should use wasm-opt to reduce the size, possibly along with compilation flags like opt-level='z', lto=true and codegen-units=1. Note that you should only use these for release builds for wasm. Debug builds will be way larger anyways, and you should probably develop/debug with a native build.
For features, you can look through the list of default features and disable every file type you don't need. That's an easy and safe option. Audio is another thing you might not need. You can probably disable some PBR rendering features as well.
@rust_osm_tb sorry, for the late reply.
SceneRoot is for GLTF, you would need something similar. I told you about it as an example you can look at, not something you can directly use.
Lights: You will want an AmbientLight which is relatively bright, to make shadows brighter. Then you'd want a DirectionalLight as your Sun, with an illuminance of 32000 or above, for direct sunlight. You'll likely want a soft_shadow_size: None to disable soft shadows.
@rust_osm_tb Entity isn't a class. Its literally a integer. Its like the primary id of a database table. Like the index of an array.
In Bevy, many things are entities, and slowly more and more things are made into entities. The window is an entity. Observers are entities. You may have many intangible things as entities too. You have to keep in mind: ECS is a paradigm for managing program state. Whether and entity represents things which should be rendered or abstract concepts is entirely up to you.
Rust & OSM (TB)
laund