Procedural galaxy and streaming

Nice! Are you doing a tree with hard requirements like in Civilization, or you add some randomness like in Stellaris?

This is a pretty fun project.

Love the detail in the tech tree!

hey thanks. The tree is …err … “special”. Apologies to our beloved mods, because this is not about BJS or 3D :stuck_out_tongue:

@CrashMaster thanks! :slight_smile: requirements are hidden, whether before unlocking a science, or even after. I did this for several reasons:
. make the tree less predictable
. make the tree more “mysterious”
. make the tree more dynamic, in the sense that it contains so many relationships (number of sciences * number of aspects * number of factions) (~= 25,000 relationships * number of factions) that it becomes a gold mine in terms of customisation, etc. May I suggest you read the following posts to know more?:
. Ad Lumens - Tech tree, the embryo
. Ad Lumens - Tech trees and pâtisserie
. Ad Lumens - Aspects and Sciences
. Ad Lumens - Initial "Tech tree" released

I admit I struggle to explain it sometimes. My daughter (a fantastically bright human being) told me I lost her at “manifold mille-feuilles” xD … I strongly suspect she was calling her daddy a nerd …

@Pryme8 thanks too! Although I am not 20% there for the details. I still do not like many descriptions and many of them are still … well they still aren’t! Plus I need to add all the blueprints while also coming up with posts that will explain how they work.

Lots of work ahead.

Have you guys “registered”? I know it sound like an insult nowadays, but having constructive people interacting with … for example galaxy bookmarks would help me build another Tools & experiments subpage :slight_smile:

Thank you so much

PS: I still have a large chunk of sciences to add (they are in-system but in draft mode), mostly linked to the “human sciences” domain.

1 Like

Such a cool project, I love it!

Hello all :slight_smile:

I have reworked the communication protocol between server and client (proper clean-up server-side with a nicer python hierarchy and organisation of dataclasses, etc) and a little bit better/organised client-side (it very very quick and dirty before…)
The payloads are thus a little bit lighter (not by much but 5% is 5%).

The 3d explorer now shows the per-second bandwidth usage, both for upload and download. not very useful but nice :stuck_out_tongue:

Now on the client-side: I have started experimenting with workers on this project. But I have an issue: since the payload are all pregenerated server-side, the only actual cost is to render and not randomise, etc.

Is there a more documented way that this to offload to one or more workers?
Would you have any suggestions?

Many thanks!

1 Like

Hello!

The 3d explorer now makes use of several workers. It seems to have indeed lightened the load on the main thread and some stuttering from before (due to objects insertion in the scene, etc) happen far far less frequently. Now I haven’t tested with a 486SX, but any reasonable CPU should be ok. :slight_smile:

Very quickly:
. render thread handles an offscreen canvas
. network thread handles msgpack-ing and unpacking to and from the server. So all client<->server communication goes through this worker eventually.
. the main thread handles the UI and routes messages between workers (when and if necessary)

There is one thing I would particularly get this great community’s feedback on, however. The main thread still handles a canvas with BJS, etc. With only a flycamera and not other objects at all. Questions:

. would the overall load of this canvas be negligible? I would assume so but…
. the goal of the “extra main ui canvas” was to leverage all the BJS code for movement, etc, and not having to reinvent the wheel. Knowing that the main thread then updates the render worker with camera position/rotation, do you think that was a good idea?

Many thanks!

1 Like

Well the stuttering are basically gone, nice :ok_hand:

would the overall load of this canvas be negligible? I would assume so but…
. the goal of the “extra main ui canvas” was to leverage all the BJS code for movement, etc, and not having to reinvent the wheel. Knowing that the main thread then updates the render worker with camera position/rotation, do you think that was a good idea?

Having the UI canvas with just a camera should not be too much even for a potato. I mean what do you want to do with the main thread that would justify optimizing this? Do you want to run it on phones? I don’t really see that part as a bottleneck for your project.

I think that if it works and you don’t really need the extra tiny bits of performance, you should keep it that way because handling inputs is a pain and time consuming :slight_smile:

Speaking of inputs, some camera inertia would be a nice improvement on your controls imo :wink:

Thanks :slight_smile:
Yes I think we can both agree that leveraging the “onscreen canvas” for movement/input is probably a good idea. :slight_smile:

There is no inertia? :face_with_spiral_eyes:

(apologies for late reply, had to jump on a plane to south america to go help a very close relative of mine…and fix a situation … .no kidding)

Sorry I was not specific ^^ There is translation inertia, but when using mouse drag to rotate the view, it feels very stiff (see attached video) and adding some inertia might make it feel better :+1:

No problem haha, sounds like you got quite a situation x)

Dear all,

I’ve finally come round to releasing a first version of those tectonic surfaces (see Icosphere + ROAM; test and questions)

https://adlumens.org/tools-experiments/tectonic-surface/

( and a quick post about it here: Ad Lumens - New Tools/experiments page: Tectonic surface)

I hope you like it!

That was an interesting read, keep up the good work :+1: I must say I expected it to run slower ^^

hey hey :slight_smile:

thanks – well it is reasonably fast because it’s not (yet) doing everything I want it to do. But as of now, what do you think of the quality of the output? in terms of elevation only I mean…

I think large scale features look nice and coherent based on the tectonic simulation! (Still think the mountains are not pointy enough)

The plateauing is a bit weird, but that’s because it is meant to be underwater probably?

Going close to the terrain can lead to high frequency bumps like this:

This might be because of the dimensions I chose (50km radius), that’s less of an issue for 500km :+1:

Thank you!

first image: I think I may have reduced/removed the plateau-ing effect (it is now commented in the code, as I want to introduce it later for [potential] continental .. err.. plateaux; this will not always be present and will depend on intensity of tectonic activity, compound composition, etc and yes, under liquid [not necessarily water])

second image: yes you are right; the displacement “scale” is hardcoded to “10km” for now. So a 20km wide “planet” gets the same as a 5000km one. Which explains those monstrous bumps. One of the things I need to work on :stuck_out_tongue:

re: pointiness. Yes I agree they are rare, but sometimes you get areas similar to this? :slight_smile: In such as case, do you think they are pointy enough (knowing that erosion, etc is not there yet!)

Liquid methane maybe :eyes: ?

I see ^^ it’s fun de try different scales to see how the terrain behaves. I tried 5000km and the resulting terrain is better indeed.

Yes this picture has nice pointy moutains, maybe they are a bit too rare x) If you add some blue color for terrain below the water level it would be easier to find them as well imo :thinking:

Liquid methane maybe :eyes: ?

Oh yes! Otherwise why did I spend so much time working on these :slight_smile:

Although… the numbers above are based on very very very rough phase diagrams, the presence of seas, lakes, glaciers, etc, will be far more based on “let’s just try and make it look good and not too unrealistic” :slight_smile:

I see ^^ it’s fun de try different scales to see how the terrain behaves. I tried 5000km and the resulting terrain is better indeed.

Yes, plus to add to this will be the overall “activity level” of the crust (dimensionless). And a small potatoid will have zero there…

Yes this picture has nice pointy moutains, maybe they are a bit too rare x) If you add some blue color for terrain below the water level it would be easier to find them as well imo :thinking:

The local prototype has that. It helps my monkey brain understand water/plain/mountain more easily, but I am actually and actively trying to avoid that! These are supposed to be alien worlds nomdidiou! :stuck_out_tongue: I still have to have a randomly generated place that is close to earth and inhabitable by “baseline” humans without terraforming and the like.

But you are right I think…perhaps they are a little bit too rare …

I’m having fun // je m’amuse comme un petit fou :slight_smile:

Converting these phase diagrams in usable functions must have taken quite a while, I only did water for now on my own project :laughing:

Haha true, but not easy for us, biased monkeys ^^

C’est le plus important :slight_smile:

Converting these phase diagrams in usable functions must have taken quite a while, I only did water for now on my own project

Since they are extremely simplified, actually not that hard. Just.. err.. time consuming (I knew a few by heart once upon a time, but 50 … no … so had to look them up and “linearise” them so to speak)

C’est le plus important

Oui. :slight_smile:

1 Like

ha I got one!

Super venus (5.5 earth masses) : 147 atmosphere surface pressure, 245 Celsius surface temperature.
Paradise :slight_smile:

perfect place for vacations haha :ok_hand: quite unforgettable. How does it still manages 2% ocean coverage :thinking: ?