To rbfx and not to rbfx

Indeed - with rbfx having diverged as much as it apparently has - it should probably not be considered much different from the other open source engines out there with a compatible license when it comes to adopting certain features.
Also, welcome to the forums! :confetti_ball: :slightly_smiling_face:

That’s a reason not to fork.

2 Likes

Yes, mostly this.

If we are talking about some feature, e.g. container library, it can be in 4 states.

  1. It may be completely finished.
  2. It may stagnate (this is what happening with Urho Containers now)
  3. It may be supported (thats what we did with Urho Containers before, e.g. I added move semantics for Vector)
  4. It may be delegated to 3rd party (like we did in rbfx)

I personally cannot understand why choose to stagnate when there is available option of developement. This should be default way to go – to delegate support if there is reasonably lightweight open-source 3rdparty. We don’t have custom physics or custom image decoder. Why have custom containers?..

And Urho containers are not finished, they are missing a lot of features.
Small buffer optimization? Forget that. Allocators? Nah. Algorithms? Nope. Containers except vector and hash map? No, there is none. Move semantics? Barely. Spans and string views? Phew, nope, we will write copy-pasted foo(const char*) and foo(const String&) instead.
I would have never finished my lightmapper if I had to deal with ever-lacking custom container library.

That’s why I hate forks. Always said this much.

Are there any changes in the rendering system in rbfx that can impact urho?
Will we able to alter the rendering system in the future, for instance by adding angle-vulkan-metal support? Or whatever else?

1 Like

rbfx core is almost identical to vanilla Urho, including renderer.
The biggest change is lightmap/light probe support and even this is only a dozen of lines here and there.

1 Like

Hygienic forks can be healthy extensions. :wink:

1 Like

@Modanung Thank you!

I totally agree.

@Eugene But the Urho3D Editor is not required at all, neither it ever appeared to be the focus. Always thought it was just one of the samples of the Engine.

You say that both engines share 95% of the codebase, but also that the merge would be package deal.
I have to ask, for that 5% difference, why does Urho3D have to change to accommodate rbfx?
Why doesn’t rbfx change themselves instead to be compatible with current Urho3D?
The EASTL change is, at best, debatable.

Please, do not take this the wrong way, but, in corporate terms, this almost looks like a “hostile takeover”.

It’s like SystemD all over again.

I am offended. Hostile takeover would be us pushing rbfx and making Urho3D obsolete. Which is happening already.

Well, that is exactly what I feel when a project requires another project to change considerable itself instead of changing themselves.

And this is one more issue of vanilla Urho – it doesn’t have real full-featured Editor.
If you personally don’t need it, it’s not the reason to deprive others from this feature.

EASTL, plus we are not going to maintain AS in any way.

I see only two options of developenet here.
Either someone is willing to make Urho Containers as usable as EASTL, including all the features I mentioned above, or we are delegating this piece of maintenance to 3rdparty (e.g. EASTL).

I don’t see any volunteers for the first option, so it’s not like I have any choice.
I also don’t consider stagnation as an option. Users who are willing to stagnate can always use outdated branch or fork.

Why would anyone volunteer to change something that works well to support something they do not want.

And what about the choice if not merging rbfx at all. Unless that’s not an option.

What made Urho3D not obsolete for you, when first encountering it? Why not go Godot?
To me, rbfx is just one among a myriad of comparable options. It no longer stands out, unlike Urho.

1 Like

That’s your biased opinion. Urho is alive and well and widely used. Just because a fork has bells and whistles doesn’t mean the original is dying or becoming obsolete.

As for the EASTL vs. Urho, that’s a discussion that should be done separately. Outsourcing complex things is one of the things Urho does well (very good libraries being used for many different things). However, I disagree that EASTL is more active than Urho. Just look a their repo: no leadership, no support, no release schedule, nothing. Just a bunch of fixes here and there by users. How is that different from what Urho has today?

1 Like

If you need only 5% of container functionality, it’s your choise.
There are people who need more.
Why these people have to deal with underimplemented container library?
There’s thin line between “lightweight” and “lacking features”, and Urho Containers are more second than first.

I have created this whole topic for the sole purpose of discussing this question.

Sorry, WTF?.. EASTL is developed by EA (as you could have guessed), it is curated by a person from EA, and they periodically push releases.

The difference is that EASTL has about 20 times more features than Urho Containers.
And these features are must have for me.
For example, strings and vectors that don’t allocate memory.

And yes, EASTL is also updated. Unlike Urho Containers. HashMap still doesn’t support move semantics.

1 Like
  1. Urho is defined as lightweight; avoiding encumbrance
  2. Editor would probably be best as a seperate repository, with pre-built binaries

@Eugene How about std containers?

1 Like

Ok, my (very opinionated) pov:

  • angescript - I don’t use scripting. I hate scripting. Die!

  • C# - same. Moreover, it is going to bring all those use virtual-machine don’t-want-to write-too-much code pimps into the engine oh-my-what’s-this-make-shared-thing-here

  • Lua (subject-related) Another vm. Ultra-die!

  • Python(more subject-related) - could make an exception for it as a scripting language. It’s on the rampage. Sleep safe C#. Discarded Godot in the first place because they messed with it so badly… (and in the second place… when I checked the sources, recoiling in horror)

  • editor - I’m on Mac and it never really worked here. So I’ve learned to live without it. Use Blender. So as you like it.

  • stdlib - Of course 10 years ago C11 was in its infancy, so having own containers/std had a meaning. Now no more. C11 works and it’s here to stay. Die C!

  • light mapper and co. - good and good

  • bad behaving forking guys & the forking turf wars - bad and bad

  • happy community reunion and following drinking champagne cheers-up - sweet & tender

:cow:
Lo and behold, the prodigal son returns

  • …so basicly ok until Urho’s name stays Urho, rbfx is rejoined into Urho, and the engine political management doesn’t change…
3 Likes

I’m not a fan of containers, to me though urho’s container is simple to some extent, as long as it is usable, it is good. I used other opensource game engines before I don’t see we are required to use powerful containers. Especially Urho is. C++ based game engine, KISS is an important characteristic among game engines out there. Additionally, there is no critical features we really need from rbfx, though I love Eugene’s embree lightmaping solution. I integrated Beast (lightmap midware Unity usefit before Enlighten, was bought by Autodesk, and dead?)before, I know how important lightmap for most of 3d games.

More importantly, we need better PBR, Metal, Vulkan, better editor, and lightmaping.

Currently, Urho is not very “useble”, if we are talking about making a game.

Well… std containers are environment-dependent, they miss some really nice features, especially before C++20, and they cannot be extended with addons and adapters to simplify code migration (like I did in rbfx).

So, about STL in Urho… Maybe in the future – yes. Now? Nope. EASTL is the first step in this direction anyway.

Well, I used vanilla Urho for years, Urho Containers are ok-ish. But every time I needed something I had to extend them. I have refactored Vector<T> two times instead of doing more useful tasks.
So I have legitimate reasons to dislike Urho Containers, if only for time I spent polishing it.

IMHO, Python s*cks for an multiplatform game engine. There is no light weight and multiplatform VM, and it is very slow general ly. I love its expression and rapid dev, but I can not find a solution till now solve the two critical issues. I think that’s why Godot choose to implement a Python look and feel language in the first place.

1 Like

Sadly that. Just another pointless, slow scripting thing… no use for playing… :confused: :confused: :confused: