To rbfx and not to rbfx

Hi everyone.

In this topic I want to discuss fork of Urho3D known as rbfx and possible feature merge from rbfx back into original Urho3D. This topic is not a proposal or announcement but the opening of discussion.
I really don’t believe rbfx and vanilla can be merged completely, but I’d like to bring them as close as possible.

In case you have no idea what I’m talking about, here is the link to rbfx:
https://github.com/rokups/rbfx

Initially rbfx was quite close to original Urho3D (I will call it vanilla from now on) in terms of codebase and feature set.

However, the divergence grows as time goes on.

And this divergence becomes really annoying for users of both projects.

I cannot make wide-scope changes in rbfx because it will make things even worse than they are now. I cannot merge my changes into vanilla because it would require tedious rework of codebase. Users of both projects cannot simply switch back and forth because API is already incompatible to a certain degree: it’s nearly impossible to write code working both on vanilla and rbfx.

Oh, I hate forks soo much. And I don’t want to repeat the story of Atomic.

What does rbfx offer and why bother?

There are several major and multiple minor features, including native Editor (WIP), automatic C# bindings, built-in lightmapper that you all have probably seen, universal user-friendly serialization from/to binary/XML/JSON instead of this terrible (and sometimes broken) x6 copy-paste in vanilla Urho, profiler, type-safe logging and string formatting using fmt, subdirectory support by build system and so on and so on.

I’m planning to do some major renderer changes too, but I won’t make any promises here.

What’s the problem with “just merging” everything back into vanilla Urho?

Short story: there are breaking changes. A lot. And a lot of dependencies between features too.

So it’s actually impossible to merge rbfx into vanilla “by bits”: it’s a package deal, and the package is huge.

1. The broadest (in terms or API affected) breaking change is using EASTL standard library instead of custom Urho containers. Yeah, Urho containers may have some nice features, but they are sorely lacking compared to EASTL or STL libraries. I personally switched to rbfx just because it’s so much easier to write code with standard containers. Maybe in the future it would even be possible to take the next step and switch to STL completely.

   This change is mandatory to merge anything else from rbfx into vanilla Urho. It will also require certain rework in script bindings. Lua would probably be easy to fix because it has compile-time type checks. AS would be more painful. Speaking of which…

2. The biggest (in terms of functionality) breaking change in rbfx: AngelScript is gone. Forever.

   You see, AS is assembly library. Just think about it. Urho is using raw assembly right now in 2020. Not just for optimization, but as scripting core. AS has zero compile-time type safety, so if you make a mistake or forget to update some manually written binding code, you will get real-time crash, or UB, or data corruption, or anything. Manual and fragile bindings to AS greatly decrease code maintainability.

   Consequently, vanilla Urho Editor is gone. Yeah, writing Editor basing on AS scripting sample was a mistake. It’s sad because vanilla Editor is quite nice and has a lot of features. But it is really hard to extend due to poor architecture and using AS bindings instead of propper C++.

   Theoretically, it’s possible to merge stuff from rbfx and keep AS and vanilla Editor. However, I’m not going to do anything for it – neither to fix conflicts on merge nor support manual bindings, ever. Feel free to volunteer for this task.

So, what do you think?
Is it worth a shot, or I want too much?
Is it better to try to bring rbfx and Urho closer or let them diverge forever, essentially becoming separate projects?
It’s not too late yet, but every major update in rbfx will make things more complicated than they are now.

Here are some polls.

About possible merge

And about AngelScript specifically (assuming that you will get native Editor as replacement):

Damn, I’ve spent hours writing this chunk of text. Please don’t ignore it. Thanks.
I’m summoning here all ppl I can think of.

@rku, @weitjong, @Modanung, @Miegamicis, @JTippetts, @JTippetts1 (I have no idea who is real you), @boberfly, @Dave82, @Lumak… And I hit the limit of mentions, sorry if you aren’t listed here. I’d summon @cadaver too, but I don’t think he have strong opinion on the subject.

As long as that C# filth stays far away…

Here are my 2 cents of this proposal.

It was actually one of my plans to get some parts of the rbfx back to the Urho. It has a lot of nice features that Urho lacks. It’s sad seeing AS go, but I guess it’s the right thing to do.

I know there are a lot of guys out there who don’t want to see the C# support in it, but I guess it’s fine as long as it’s a optional dependency and by default the engine is built without it. (note: I’m not too excited about it either)

I have so far been completely unbothered by the presence of the C# stuff. Was skeptical at first, but it really is separate.

I believe this would be a foot in the door of a slippery slope to soullessness.

-DURHO3D_CSHARP=OFF

@rku Or people could be pointed to rbfx for that. I believe this is exactly the dispute that inspired you to fork Urho in the first place, correct?
Most other effort stuck into rbfx could have been applied to Urho3D.

It’s actually a technical question, we can’t make our decision based on our emotions or religious beliefs. Nothing is decided yet, we as a comunity have to agree what’s best for the engine.

In regards to removing AngelScript, is C# a usable replacement if the only use was in a handful of scripted components and plugin type things called from within C++ code, or does the C# code have to be the main application?
Is there a way to do something like CallCSharpFunction("doStuff(int)", 42) and get the result?

Hello, this is my first time using the forum although I have been using Urho3D for about 2 or 3 years now.

I would like to say that I think that this proposal is a very radical change.

Although I have seen rbfx mentioned before on the forum, I never took a close look at it until now.
And seeing C# and that WYSIWYG editor that looks like Unity sent shivers down my spine.

I fear that bringing C# to Urho3D will turn this into a nightmare, and, in time, will root itself permanently into the core of the engine.
Given how traumatic apparently merging the changes from rbfx to Urho3d will be, I am afraid that that will almost certainly be the case.

To be quite honest, I would like to see even AngelScript and Lua completely removed from the engine.
C/C++ is not that hard and it tends to force the developer to know what he is doing and to program properly and efficiently.

In my opinion, bringing C# and WYSIWYG to Urho3D is steering the ship on the very opposite direction of what Urho3D is now.

I only ask that if this goes forward, please, announce it early so those that don’t like this direction can have time to fork Urho3D or move to some other engine or library.

I don’t like AS because it has no IDE or real useful debugger which supports urho. I don’t see scripting is useful in a serious project without IDE support. I don’t like C# because it is heavy and pain to maintain? Though its IDE and stuff would be much better.

Urho’s container is good IMO, light weight as Urho itself. Not as powful, but easy to read and use. Just like Urho. Why we like Urho, because it is simple and nice. Otherwise I would just use UE4, Unity or Godot.

The worst thing about Urho is Editor and workflow. IMHO, rbfx is better in some aspects is because the brave author has been really working hard on it.

If Urho also has a IMGUI based editor, people would be much optimistic.

C# bit uses sort of a “hack” where main exe is .NET. This is so we can support multiple runtimes without writing code to host managed runtime. This is just a detail though. You can write most of your code in a .dll. Editor is a good example of large native application that gets loaded as a DLL. You do not even notice that it isnt a native exe.

CallCSharpFunction bit is possible (terms and conditions apply!), but someone needs to write it.

You do not have to use it as it is optional.

@adhoc99 Hear hear and welcome to the forums!

Why is merging rbfx stuff back into Urho necessary? They’re essentially different engines, with different goals. If people like rbfx, why not continue using it and supporting it?

It is not necessary. It is just merely an offer to progress the project.

“There are several major and multiple minor features, including native Editor (WIP), automatic C# bindings, built-in lightmapper that you all have probably seen, universal user-friendly serialization from/to binary/XML/JSON instead of this terrible (and sometimes broken) x6 copy-paste in vanilla Urho, profiler, type-safe logging and string formatting using fmt , subdirectory support by build system and so on and so on.”

I’m using my phone to type. To me, many of the features seems can be implemented without breaking the vinila and some are still optional.

This is quite funny to read about “bringing WYSIWYG to Urho3D” because vanilla Urho Editor is the stereotypical example of WYSIWYG editor.

How on Earth can it happen if is impossible to even build C# in some supported configurations?

Unusual point of view. I wouldn’t say Urho containers are easy to use. They have maybe 5% of EASTL functionality and I had to write several times more code with Urho containers.
And this is after all the time we (me including) spent on improving these containers.

When two engines share 95% of codebase, I cannot really call them “different”.

Because it is a waste of manpower to split efforts on two projects when same effort can be spent on one.

It is possible to merge these features without breaking vanilla, true.
If someone is ready to do tedious manual merge every time either rbfx or Urho3D are updated.
Who is going to do that?

So, you’re basically saying that you want Urho3D to be rbfx.

I basically said the opposite in the very first paragraph of this topic.

I won’t miss rbfx since we have urho. Is it because of the underlying container change which makes feature merge difficult? Brave move for rbfx at the first place. I respect the author but dislike the change of stl introduction based on the destroy.
.

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!

That’s a reason not to fork.

Yes, mostly this.

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

0. It may be completely finished.
1. It may stagnate (this is what happening with Urho Containers now)
2. It may be supported (thats what we did with Urho Containers before, e.g. I added move semantics for Vector)
3. 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?

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.

Hygienic forks can be healthy extensions.

@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.

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?

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. 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?

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

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…

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.

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

Basically, AFAIK, there is not clean and fast way to run Python on Android, iOS and web.

Edit: I’m a fan of Python. I developed a packing tool with 200 loc while my coworker writing 3000 loc with MFC.

It’s time to bring the dying fish from ICU room who gave us hope and abandoned this project.

In regards to the containers, there are a few things I like more about the Urho containers (like CamelCase on the function names, which I prefer, and a couple other things I don’t remember at the moment), but I would be in favor of switching to a more complete 3rd party solution, as long as we didn’t lose features from it. I’ve run into issues with Urho’s containers a couple times, and it would be nice to gain the extra features without having to reinvent the wheel and implement it myself. Beyond that, containers like the stl ones are the most likely to have already made solutions for script bindings, so implementing script bindings in the future could be easier that way (for those of us who do like having script bindings).

So I support switching to the new containers, though I don’t necessarily support all of the changes (like removing AngelScript).

Ue4 use its own containers, if we want them more powerful, heros can improve them. Personally, I prefer keep using current containers or embrace the future and radical change by using cpp std. I used to stay in a team where people wrap STLPort and make their own containers. I guess they want safer interfaces and an unified look & feel with other parts of the engine, or they might find stl is faster, such as memory and cache optimizations.

So about STL or STD or Urho Containers, shall we start a new thread?

Edit: I don’t have such a container sucks experience before, pls educate me.

Also, @Eugene, could you explain this in more detail, I didn’t see any info when I (briefly) checked the rbfx wiki?

I don’t think we need separate thread, because this topic highly corellates with subject.

If we want to stick with Urho containers, then we cannot merge code from rbfx to Urho.

If we want to move to std-like containers, the most reasonable thing is to pick already ported code from rbfx. We don’t even need to pick anything else from rbfx: container migration alone will close 90% of the API gap between rbfx and Urho.

I see only one issue with std. Somebody will need to do huge and tedious work of migration of whole Urho codebase at once. Some parts of code will have to be heavily rewritten, like Variant.
But migration to EASTL is already done.
Moreover, once you migrated to EASTL, you can migrate to std incrementally, file by file and place by place.

Here it is.

For complicated objects like Node or Serializable this looks scary, but this is just one function instead of 6 that do all binary/XML/JSON input and output.

rbfx/Node.cpp at master · rbfx/rbfx · GitHub

For simple user objects serialization is trivial:

If rbfx already has EASTL, and C# and the WYSIWYG are already implemented there, why not just move there and continue development there?

It looks like the most logical move, since rbfx is already done and working.

I am certain that the success and innovation of the fork will speak for itself and more developers will certainly follow.

P.S.: Stagnation is not necessarily bad. Things do not change and and break constantly.

Are you basically suggesting us to do exactly what we are already doing for last 1…3 years?..
I and some other people “moved there” long time ago and “continued developement there” too.

And guess what? Not everyone is happy that Urho misses some useful contributions that rbfx receives.
You ever considered opinion of people who both want changes and to stay with vanilla Urho?

You are arguing with me as if I’m the one who needs these changes.
I don’t need this merge and I’m not enthusiastic about it because I have already moved to rbfx.
I just think it would be the most optimal way to utilize resources and I like being optimal.

What’s the most logical: to split or not to split already small community second time?

Stability is not necessarily bad. I’d say, it’s good!
Stability is when there are no changes because you have enough and you don’t need more.
Stagnation is bad.
Stagnation is when changes are needed but they are hindered by obstacles, like container library written for 20 years old technologies or manual fragile bindings with zero compile time checks.

Whether the Urho is stable or stagnating… I’m not sure. I think, in between. It has a lot. It misses a lot.

Is someone forking rbfx?

I was talking about Atomic. It had it’s own quite big community, and when it died this community just dispersed into nowhere. I’m not sure how many ppl made it back here.

Let’s not forget UrhoSharp, another fork which added C# and died. Just like Atomic…

If they are not happy with Urho3D, why didn’t they already move to rbfx, since it has all those amazing improvements everybody must want? Nobody knew about rbfx? Maybe nobody wanted that?

This question is meaningless. People who are “not happy with Urho” moved already.

What about people who both want changes and to stay with vanilla Urho?
This is the most voted option in the poll, if you didn’t notice. People who want changes and want to stay. I was one of such people for a long time. Maybe I still am – I’ll return to vanilla Urho on first opportunity (when it gets real container library and native editor. And no manual bindings because they suck so much).

Anyone who votes to removing AS is at the same time voting to removing the console…

Can we have lua console? Lua is at least safe and semiautomatic.
And AS removal is not required to merge changes from rbfx as long as someone will patch AS bindings for EASTL. I have no idea how hard it would be.

I hate GC and ugly Lua syntax. If need choosing from these two, then I will choose AS

The question is absolutely relevant. You are assuming everybody wants that. If they did, they would be there already.

Those who want both should really move to rbfx, since it’s just 5% different and EASTL is clearly so much better and has so much more development going on.

Yeah, the poll, sample size of what, 15 people? And how many already are on rbfx? I wonder actually how many users even use the forum.

Shouldn’t be Urho3D actually asking to be merged into rbfx?

Why don’t you ask all these people who voted for changes why they don’t want to move to rbfx if you want to know the answer that badly?
Why are you asking the one who did move?
I’m, like, the worst possible interviewee to ask such question.

I can only tell for myself. I didn’t want to use rbfx because I hate forks and I think it’s suboptimal use of resources.

It tells a lot about how many active users Urho actually have.
I’d like to get more votes, but it’s not like I can force all these people to appear here.
I will work with the data I have, extrapolating it on the rest of hypothetical users that may or may not exist.

Seems to me like this overhaul would introduce a lot of work that would cause existing issues and PRs to get snowed in. If you want to work on Urho3D, do so, but let Urho be Urho and may rbfx fill a niche of its own. If you regret working on the wrong engine, rest assured in the fact that you gained experience while doing so.

I’m counting 23 users with visits during the last week, over thirty in the last month.

The poll tells literally nothing. Most people just use the engine and never even step here. I have been using this for 2 to 3 years and never even bothered to join the forum.

Sure, because 10 votes (and 4 of them already use brfx and I have no idea what are doing here) represent the totality of users of the engine. Maybe checking how many clones or downloads the repository have would be a lot better indicator of the real userbase.

I am asking you exactly because it was your proposal.
So, you do not want to use rbfx, but want to merge all that here.
How is that more logical than just moving there?
What does Urho3D have that rbfx does not?

You mean these existing issues that nobody is going to fix?

It sad and funny that people want to get functional improvements, but when said improvements are basically offered the same people are complaining about the price (relatively small) that they have to pay.

It took me 10 minutes to move my project from Urho containers to EASTL and it already saved me ten times more.

I heard there are some rbfx developers that miss working on Urho3D.

Soon it will be
Like in the days before

And we have no information about said people and what they want.
We also don’t know if they would use rbfx given choice.
Urho3D is indexed and relatively known, rbfx is not promoted in any way.

Either I’m writing too cryptic or you are outright ignoring what I’m saying.
It is the waste of human time to work on two divergent codebases when it is possible to work on two partially synchronized codebases.
I don’t know how else to explain it.

Also, I have a question.

You say you want changes, but when you are offered functional improvements with relatively small price… You don’t want it anymore, because you will /gasp/ have to spend an hour to migrate your code to the new version.
What do you suggest then? What should be done instead? There are people who want to work with Urho and who need better container library. What do you suggest to do for these people?

Those breaking changes sound significant. In changing the containers, my existing programs are going to have to change, is this a drop in replacement or will logic have to change too. I guess I won’t have to worry about moving my Angelscript programs forward. I could use C# though? As the rbfx wiki page says “ C# support is experimental It may not work correctly, fail or crash in spectacular ways. Managed APIs will likely change in the future.”.
To me, it sounds like some of these changes could be moved into Urho thru the Issue/Pull Request route and that way, it could be peer review and argued about.
Dropping AS, Lua is interesting. For me, this would be the end of Urho and the start of rbfx, and anyone that had existing programs, they are done, choiceless.

Could we add another poll about switching to EASTL? If that is the primary obstacle to merging features from rbfx I feel that may be at least an important a question to ask as the one about AngelScript bindings.

They are dropped in rbfx. Doesn’t mean we have to do the same in Urho. Even AS may be kept despite its huge maintenance burden.

I believe that with adapters enabled it would be enough to just rename first_/second_ to first/second for pairs. At least in most common use cases. Adapters may be extended on demand.

Having recently switched to RBFX (~2 weeks ago) and been plugging away figuring out the differences and migrating my things over … everything I thought I was against in it really is just “who even cares, it works” once I sat down with the repo and a lot of it (EASTL in particular) eased a lot of project ping-pong friction making it much more pleasant.

Some hiccups here and there, but in general I quite enjoy the move and don’t see myself having any trouble getting most of my engine changes moved over - I’m looking forward to making PRs for some of those and porting a couple of the examples over to C# (working on 39_CrowdNavigation r/n).

All-in-all, RBFX is solid and a pleasant change.

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

That’s doesn’t resemble anything. If anything this thread was opened with the vibe of being about things in RBFX reaching a cusp where if it continues on there will be nearly zero hope of porting them backwards to Urho3D and there will be no one remaining willing to bother with that work - which will only get worse and worse.

STL containers sure would make the CMake scripts fun. Joy for adding more build targets to deal with STL switches. Mismatched STL configurations between libraries is tons of fun. /s

Bluetooth & C++ == need rope, stool, and rafters. Bluetooth & C# == nuget and get to work.

C# is the indomitable king of glue languages, that fight is long over. CoreRT along with scores of TensorFlow for C# flavours ended it permanently without leaving reasonable ground for retort.

I think you’re forgetting that C#-lord Unity is constantly botching everything they do and C# in master will likely bring a much needed talent infusion from the periodic handfuls of expats.

So, instead of working to promote rbfx, the idea is just move here. What a great idea.

Also, maybe it’s not promoted in any way because nobody else cares for another C# WYSIWYG Unity-like.

I want no changes at all. Specially C# and EASTL.

How about moving to rbfx and continue rbfx development at rbfx. By what you describe, it will superseed Urho3D in no time.

But hey, what do I know. It is not like Atomic and Urhosharp failed hard, right. This time it will be different, for sure.

Neither of them captured contributors like RBFX has though. The commit logs alone show that almost all active talent has moved to RBFX. Urho3D is left with @SirNate0 @1vanK and @weitjong as active contributors of note.

The commit history sealed the deal for me to make the move, I recognized every contributor and knew roughly who they were and what they’ve done which gave me a lot of confidence moving to RBFX.

The ideal situation is that Urho3D grabs what it can right now while it still can from RBFX and RBFX then moves forward more heavy-handed than Urho3D willing to lock into things like “we shall use Metal-ness” (or spec, w/e, just lock into something so we can sit down and do PBR right).

@adhoc99

I’d be wary about creating any hard-lined attitude about taking from RBFX as you’re likely going to be upset - I’m an asshole and I will rub your words (screenshotted) in your face when you start demanding someone port compute shaders back to Urho3D … which you will do.

You literally voted for an option “I want changes”. Are you back on your word now?

If you convince all these people who want changes in Urho to move to rbfx instead, it will be fine for me. But, I dunno, these people want to stay in Urho for some reason. Maybe we should respect their choice?

@Eugene you’re pushing it there, given what you said about ASM for angelscript, I could carry that off into CoreRT hate since CoreRT runs on ASM. I didn’t bother touching on it snce I assumed you just never reached that level of education to understand why AS uses ASM for thunks.

I am quite disappointed in the discussion. Nobody is talking about technical aspects of changes. Most vocal voices focus on what they want personally. There is absolutely no regard for what other people might find useful. If you do not need it - does not mean everyone else does not. If you do not like some feature - you do not have to use it (except for containers). And worst of all - nobody advocating for no change said “i will step up and maintain containers/bindings/etc”. And most confusingly poll indicates exact opposite of general vibe in this thread.

So please @adhoc99 point out some technical problems with proposed approaches. Point out how your important projects will get hurt. Do you have a commercial product that depends on maintenance of current codebase? This is important information.

@Sinoid CoreRT is not officially proposed solution any more. Seems like .NET people are going to use something else from AOT. So using CoreRT would be just like using any out of tree dependency - it would not impact upstream project in any way.

@Eugene my remark is mostly moot, just bitching about in regards to AS. Core RT also uses ASM - is CoreRT terrible too?

You said Urho3D is not truly cross-platform for having platform specific ASM for Angelscript.

Urho3D uses SDL2 which is not truly cross-platform anyways as it doesn’t support GearVR and numerous other targets.

I’m not against assembly in general because obviously it always boils down to it in the end, therefore some tools must use ASM in some way.

My issue is that platform- and compiler-specific assembly library (like AS) requires much more support than C++ library. And I don’t think that benefits of having ASM are overweighting the costs in case of AS.

And I mostly hate brittle manual bindings that are made using ASM in AS, not the ASM usage itself.

So super fast native calls weren’t worth it in your opinion?

That’s the whole point of AngelScript. Say it on record, “I’M AGAINST FAST NATIVE CALLS”

Edit: yes, I’m going to screenshot your response because there is none … you’ve probably figured that out.

Chill. We all need to chill down.

Super fast native calls are good.

Are super fast native calls worth highly increased maintenance burden in case of AS specifically? I’m not sure. In case of AS it’s not even obvious what bindings should be used — just look at all these flags. Did you know that replacing empty-body class ctor with default ctor breaks AS bindings?

I’ll rephrase myself. I don’t have issues with ASM inside AS but I hate that it is lays bare open for end user.

CoreRT makes those calls for basic allocations however, ASM is invoked for all struct allocations. CoreRT pretty much murders all reason.

Who is wrong? Angelscript for using Thunk ASM or CoreRT for using ASM for thunks and memory?

If AS is wrong for using ASM then all Urho3D users should line up to die.

Yikes. This went pretty far out into the weeds. It’s a pretty straightforward question, I think, and not really warranting a holy war.

A bit of clarity.
AngelScript not using asm in binding process - it just some aripmetical tricks with provided function pointers, and it transparent for programmer. All the programmer needs to do is write the string with the AngelScript’s method description correctly. The AngelScript uses assembler to package arguments when making an native call, and this also remains behind the scenes for the platforms it supports. C# does exactly the same thing, because it is not magic that it call to native functions.
The only difference in the details is that the bindings from C++ to the AngelScript are created manually, and to C# it done automatically using SWIG. And if SWIG is mistaken somewhere and forms the wrong binding, everything will fail the same way. If anybody teach SWIG to create bindings for a AngelScript, there will be no difference with C#.

AngelScript also potentially has a JIT - it can be embedded in the library and this will significantly increase its execution speed.
The AngelScript is much smaller than the C# and does not require dragging along a bunch of dependencies in the form of a .NET framework or Mono. Meanwhile, its capabilities are enough to implements the game logic. The only drawback is that there are no native calls for ARM64 yet, which somewhat slows down work on modern Android and IOS systems. And, of course, there are far fewer people who know the AngelScript than they know C#

I forgot one more minus of the script - there is no ready-made debugger in the library, although can add it, there are such solutions.

@orefkov, that’s thunking. Which every sane scripting language uses. Lua doesn’t because lua byte-code is so fast that it doesn’t have to bother so they use a trash stack-machine.

You have to either do like lua and fat glue or do like Angelscript and thunk to make foreign calls. These are your options.

CoreRT uses thunking for all PInvoke calls just like angelscript … so any argument against Angelscript for using ASM is outright dead because you have to call CoreRT everything you would call Angelscript for doing such.

Spoiler, you’re losing that argument so hard your babies will have broken skulls.

C # will attract a considerable crowd of newcomers, who, if they do not participate in the development directly, will make it more popular and open the issue. See the unity experience. C ++ is not what game developers want. AS and LUA are blind coding (without an IDE), the framework’s and mono behind Core steers and is optimized by leaps and bounds. I agree C # mod, but decent and deserves respect.

I am not against AS and LUA, but C # can safely and worthily replace them.

I have extraceted EASTL question into separate topic
Migration from custom container library to augmented EASTL

When you make AS bindings you lose all C++ type information about function.
Therefore the binding string directly controls the assembly that is going to perform the native call.
So when you are making a binding, you are touching asm thru very thin API layer.
Or am I wrong here?

The difference here is that SWIG is automatic and end user does not need to touch asm when they are writing their code. Once configured, it just works ™ most of the time and if user made a mistake, they will get compilation or preprocessing error.

AS have asm exposed, so if end user touches it in wrong way, the application explodes.

Can you please remind me who are you arguing with and what is the argument?..

Because I think I didn’t make myself clear enough in starting post.
My argument against AS is this part:

image841×150 22.4 KB

he didn’t die because there was c #, there was one developer and he abandoned it, because they stopped financing the project

It will also chase away a core section of informed developers, who are fond of Urho, sprouting another fork. The must-C#ers could all be guided to rbfx instead of being smeared out.

Although true that it is not the industry/education standard, when it comes to Urho3D I believe writing your programs in C++ is the community standard. There is no need to homogenize; diversity is strength.

And you didn’t notice that engine writers very rarely make games, your hands will never drop before that)
Happiness C ++ coder is a living engine)) Well, or pride that someone wrote a decent game on it … and that’s it

Changes like oh, look a bug, here is a bug fix, not hey lets change major core components of the engine because we want to add C# and turn this into a Unity.

Maybe make a giant pinned topic here advertising the clearly better rbfx where all devs moved to and so should you.
Make one in the site too.

Yeah, sure it is a great idea to tell you that.

Which I will do not. But funny you just assume stuff.
Probably I want C# and EASTL but just do not know it yet.

Which will be a total nightmare.
Oh they will participate. They will participate a lot.
They will ask absolutely [everything] about [everything]. “How do I do [everything]?” “Why does not [everything] work?” “I need an example for [everything].” “Can you add [everything] in the engine so I do not have to?”
Yeah, I would call that a pretty accurate Unity experience.

Indeed. They want is to shovel “games” as fast as they can regardless of quality or performance. And they want to do that in the easiest possible way.
C/C++ at least tends to force developers to know what they are doing and do it properly.
C# however…

Just trying to gauge if there is any serious impact on you since you are so outspoken against. So far it seems this is just your personal preference for the sake of personal preference. Let me know if i am wrong.

I’ll leave my thoughts on scripting, based on my own Urho3D usage. I may not be right but here it goes…
AngelScript is awesome, but I don’t think its attracting people. The effort and skills required to use AS is close to (as not the same as) those required to just use C++, so why not just use C++… My Urho3D based (media player like) application requires some scripting but other devs I’m working with just don’t have the skill to code on AS and enough time to learn it. They prefer having a Lua, JS or Python scripting system with running examples that they can extend and easy to find samples on the net.

I do not see big difference between

https://github.com/Dviglo/Dviglo/blob/CSharp/Source/CSharpSamples/03_Sprites/Sprites.cs
and
https://github.com/Dviglo/Dviglo/blob/CSharp/Source/Samples/03_Sprites/Sprites.h
https://github.com/Dviglo/Dviglo/blob/CSharp/Source/Samples/03_Sprites/Sprites.cpp

Just C++ works faster

There are no special differences, it’s exactly not in the code writing, but for what conveniences, in terms of quick compilation, removal of the general code, the absence of “h” files, opening on the fly in andriod, ios, etc. Comfort from the additions of the language itself and various modern programming chips. Before 3-4 years ago, even there was no idea to use c #, but take a look at it now - these are completely different things.

“Just C ++ works faster” now the difference is miserable, with the advent of Core X, optimization went uphill

Because in cases where you do need script (when sending behaviour over network for instance) AS is a god-sent to those who have been coding C++ up until that point for the same reasons. I think we all agree automatic bindings would be divine for any scripting language and is guaranteed to accelerate engine development.

Eugene: There are people who don’t want to use fork. What should they do?
adhoc99: They should use fork!

…

I think that this way of answering questions and solving problems is weird and quite… nonproductive.

Definitely agreed. But that is not happening for AS. It isnt even happening for lua even though lua is easier of two. But we should not forget lack of ecosystem around AS. It is said already that you basically have your notepad and thats it. lua at least has a richer ecosystem around it, editor plugins that support debugging even… Of course nothing beats C# in editor support. Not trying to say that Urho needs C#, just pointing out that good tools make life a lot easier. That should be of some consideration at least.

Not all that is said is true.

It is not impossible. The future is uncertain.

Code::Blocks AS editing is a hack that sort of works. It is not a proper solution.

Automatic AS bindings are possible, but nobody will put in the work to make them happen. Go and prove me wrong

This instant? You know that is impossible. But you proved yourself wrong about Urho being dead. Maybe the same will be true for AS auto-binding.

CodeLite any better?

VS2019 definitely the best

Code injecting proprietary IDEs are not a sane option.

VS2019 community forever

I am not unreasonable. Start working on it. No matter how long it will take. It is a lot of boring work nobody wants to do though… Same stands for lua by the way. It is only marginally better than AS. We have some plans to bind lua using SWIG in the future.

From a perspective of someone who is more interested in using the engine instead of making one, dropping AS would be a big mistake. Thanks to AS it’s possible to create application, that can be easily modified by the end-user. I think that we all need to agree that when it comes to games modding support is very desired feature that helps to build a community around the title and can keep even old game alive for a long time. Also when it comes to other types of applications (not games), users usally prefer to have an ability to write some simple scripts that will automate their workflow. Now I know there’s still Lua, but rbfx dropped it also and the reasons behind this move are still valid, so there’s a big chance that Lua would simply be next in line to be removed (apparently with plans to bring in back in some undefined future). In the end this will mean that changes that are supposed to make a live of a developer easier, would also limit what this developer can offer to the end user or would require additional work to bring back functionality that’s already there.
Next thing - as someone already pointed out C# support is experimental, rbfx site also states that editor is still WIP, so it seems like proposed changes mean that some parts of the engine would be improved, but there will also be a regression in other parts. I have not used rbfx so I don’t know what’s the current state of the editor (and that’s rather important tool), but if it’s far behind the ‘vanilla version’, it will also require some additional ‘manpower’ to bring at least current functionality and since rbfx is a thing for some time now, but editor there is still WIP, my guess is that’s it’s not very high on priority list there.

Finally, I must ask what’s next? Would this be a one-time ‘code synchronization’ or from now on both versions would be kept in synch (what’s the point of having two versions then?). If it’s supposed to be one time thing, than I don’t need to be a prophet to see what will happen later: rbfx users will stay with rbfx, urho users with stay with urho or even will stick to version before changes (because of the compatibility breakadge), rbfx and urho will go their own ways, after some time once again there will be too many differences, to make a project compatible (or easy to port) with both versions and we will be back in the same discussion just about different features - so I would like to know what’s the plan there?

If the community is convinced, as long as EASTL itself alone does not break things too much, we may provide some scripts/way to help people migrate their own projects.

As for AngelScript, can we make things automatic? like SWIG for C#? So we just keep lua, AngelScript and scripts based Editor, as long as we don’t have a better alternative yet so discarding any of the parts are not considerable. If people love C#, use it.

So, everyone is happy and Urho is stronger. Am I asking too much (based on the community size and contributor number)?

You are very wrong.
But I am not foolish enough to dox myself or my work.

I am very outspoken against it because it is crystal clear that this will become “Urbfxho3D”. If you guys are so proud of your amazing work on rbfx, I insist:

Oh, if you are using that logic then:

Eugene: So we will push the change anyway, because we know better and we know what is good for you.
adhoc99: Yes, yes, I welcome our future Urbfxho3D overlords.

What a brave new world this will be.

Your attitude is insulting to me.

First of all, you are ignoring the fact I mentioned before God knows how many times.
I will make it bold here:
It is impossible to merge rbfx into Urho

Second, do you maybe think that I will be happy to merge things from rbfx from Urho?
Merge is ****ing hard work! That I will be doing in my personal unpaid time.

And so I come here on forum with an offer of partial feature merge. The offer that community may accept or may decline based on reasoned discussion.

And obviously, every single contribution that I may or may not make, for every single feature or breaking change, will have to be discussed on the forum and reviewed as PR by the community on GitHub.

And here you are, accusing me of pushing rbfx over Urho as if I have just force-pushed Urho3D master branch.

Such attitude towards a person who is basically offering a gift is deeply insulting.

Oh yeah, we should be so greatful for your time, it is trully a blessing.

Behold the glorious “gift” one is not allowed to refuse.

It may be surprising for you, but you are not the community.
If you don’t want something, it doesn’t mean that everybody don’t want it too.

Behold the glorious “gift” one is not allowed to refuse

What exactly does it mean?..
Every contribution is damned pull request that has to be reviewed and approved before it goes into master branch. Can you point out how exactly pull request “cannot be refused”?

There are several major and multiple minor features, including native Editor (WIP), automatic C# bindings, built-in lightmapper that you all have probably seen, universal user-friendly serialization from/to binary/XML/JSON instead of this terrible (and sometimes broken) x6 copy-paste in vanilla Urho, profiler, type-safe logging and string formatting using fmt , subdirectory support by build system and so on and so on.

IMHO,

• universal user-friendly serialization is optional, it’s just more convenient. Can we also make one in vanilla?
• profiler can also introduced to Urho, as another outsourced feature of Urho, by using Tracy as rbfx
• logging is just optional, the vanilla one works good, I don’t see many people complain about the current one.
• string formatting using fmtis also optional, I don’t see many people complain about the current one.
• C# controversial, skip it currently.
• Without more from the list, I don’t know more about rbfx.

Editor
I checked the Editor. If I can understand deep enough, IMHO, it is still not very usable, not as featured as AS based one in Urho at least, though the latter has many issues and not pleasant to use to me. The rbfx author has been trying to make the workflow run, asset import/export… but not there yet. A lot of detailed stuff are not done yet, but I can understand to some extent the willing behind the code and the GUI. Maybe Editor is something people like Eugene really want from rbfx? But it’s far from done.

Lightmap Baker
I know the lightmapping implementation is nice and Eugene has done it beautifully, but it is based on the rbfx code, without the editor and eastl, lightmapping lost its foundation. Or maybe re-design it as a stand alone project, which allows baking by input of scene information?

I’m for the stl introduction if it really releases productivity, and happy to see more features into Urho, but I against breaking Urho for introduction of the editor from rbfx, or the Lightmap Baker, if I have a vote.

It can be ported quite easily. However, it may be more complicated to actually integrate it into existing classes. It always takes a lot of effort to break as little as possible.

This is called “quality of life update”. When you can crash application by typo in logging, it’s not very good logging library.

Lightmapper is unrelated to editor, except one optional menu item for model resources. But eastl is quite important for it.

Yes, definetely. WIP. It has basic usabiliy – I’ve made all test scenes for lightmapper with said Editor. But it’s lacking and currently under developement.

I believe so. Proper container library simplifies making changes in the engine and enables more optimizations. I don’t mean that it will make existing code faster (however this may happen too), but you can write faster code with better container library.

I’m glad the EASTL discussion has been broken out into a separate thread, because there’s more heat than light in the present discussion.

Pretty sure I know where the animosity is coming from though. De-blessing of scripting languages is an existential threat to communities. The track record from my previous experience in the Ogre3D ecology is clear. When a scripting language does not receive fully blessed support from its engine, it dies. The one person cobbling the binding together in their spare time, eventually loses interest and moves on to other things. Any work that was done on top of that scripting language, the kind of work that is immediately visible to actual users, rapidly dies with it. If you want a healthy ecology to exist around an engine, you have to decide what your scripting languages are.

Just because someone doesn’t like the risks of typeless or hand crafted languages, isn’t a reason to take them seriously. I don’t know of any engineering solution that doesn’t give you bugs. It’s all a matter of what provides a benefit in the real world and what doesn’t. What is supported, maintained, and improved and what isn’t.

I don’t have a handle on how much AngelScript ecology surrounds Urho3D, but if people rationally decide it’s substantial, then abandoning it is not to be taken lightly. Frankly in that case I’d call it a dealbreaker. And why should it matter to rbfx back porting efforts anyways? They don’t have any AngelScript stuff to backport. If rbfx devs want to become main Urho3D devs, well then they can just do it with the caveat that they won’t bother with AS, no way no how. That’s a political problem not a technical one.

I’m not in favor of C# bandwagons because I don’t like the language, and I don’t see what a 3D engine going ala C# is offering anybody over Unity. Maybe someone can explain to me why they really really want C#, and not Unity and its ecology. The vast majority of game devs who don’t put much effort into this stuff, are just going for Unity and being “happy” with the money they’re making / saving. Explain to me why they need rbfx instead.

Lua, on the other hand, is a proper scripting language, and fast for being one. It of course has tradeoffs. It also has a lot of proven use in the game industry. It’s not crazy talk to build a 3D engine ecology around Lua. I definitely see the case use for Lua instead of C#.

I can’t take the “do it only in C++” crowd seriously.

I’ve spent a lot of years trying to invent my own programming language, that would be a unified C++ and scripting language replacement. Nothing to report so far. I’ve got maybe 2 ideas, in all that time, that are actually good and should be implemented. I may yet make an attempt now. I’m currently contemplating the problem of making 3d art assets by hand typing into text files, as opposed to 3d editors. Maybe that will finally get me going.

Jonathan Blow has his Jai langauge in the hands of a few beta testers now. Maybe he’s finally going to release it onto the world?

I have followed many languages over the years, trying to overcome the “C++ and scripting language” barrier to development. Never did find a magic bullet. But it has caused me to study a lot of language ecologies. You can judge communities by what they actually get done with their languages.

If very difficult, just not do it or just stick to rbfx?

If people use some other game engines, there are also many things not perfect. e.g. UE4 is complicated as hell, quality of life will be harder if you don’t use Blueprint, cocos2d-x lacks of a lot of features by your standard. But I’m still think if we can have these in Urho style, and without breaking Urho.

Nice to hear Lightmapper is not strong related to rbfx

Until it is ready and good enough, let’s not abandon AS and keep Urho as a whole and not broken.

Just kidding you.

I’m in support of what ever you guys do. But please if you can retain the function calls to be the same? So previous code will work. Any new feature just introduce new calls.

We don’t need to see the background as long as it is faster than the current Urho. If the number of objects in animation be > 65k like Urho3d at the moment, then I will be happy.

Why not try to release 1.9 in the current working state. Then move this transition work to version 2. Any iteration of 1.9 would just then be the bug fixes?

Almost every open source project has a leader who does 90% of the work and determines the general course. Take a look at the Bullet and Box2D projects. These are VERY well-known projects and commonly used libraries. Its have a huge community. What happens when Erin Catto or Erwin Coumans leave? Even these projects will die. Unfortunately, such a fate befell our project. With all due respect to all project contributors I believe that the Urho3D project is what it is thanks to the Lasse’s vision. And we do not have a person whose opinion is unquestionably respected. On the other hand, I see that Rokups is a very enthusiastic person and has been developing his project for a long time. He has his own vision of how the project should be. Sooner or later, people who agree with his philosophy will gather around him. I believe that you should not try to merge two projects at any cost, throwing away what is a familiar part of Urho3D. Save for people the things that drew them to Urho3D.

Do you basically suggest us not to even try to contribute anything into Urho and abandon it completely?

It’s what we were successfully doing for a while, so we can just keep going.

I only believe that without backward feature merge the amount of contributions into Urho will asymptotically converge to zero.
rbfx got more updates in last year (totally unrelated to editor or C#) than Urho had since before Lasse left (maybe since 2016?)…

I suggest what I wrote. People came to Urho3D because they liked it. You want to throw away things that attracted people to Urho3D. You want to take another project, with a different ideology and impose it on everyone who is not interested. Many people move to rbfx, the rest did not. Why are you depriving people of choice? I offer a evolutionary development of Urho3D without revolution. Repair what is broken and do not throw away what works.

Don’t make me repeat earlier discussion in this topic, please.

Features don’t have ideology. They only have benefits and costs.
It matters not where do these features come from.

And if you are speaking about feature cut…
Well, I don’t know. I can see why people are being conservative and don’t want to lose anything.
But if certain features hinder development as a whole, shall they be kept?

In perfect world it is master actively developed, and release branch stagnates and is getting only bug fixes. When master stagnates because of features… this is weird path to develop a project.

I do not understand how Urho3D interferes with the development of rbfx. Personally, I believe that people are smart enough to click on a link https://github.com/rokups/rbfx if they want a different set of features.

You see, it doesn’t not.
It’s the best case scenario for rbfx if Urho just stays in its current state forever.

But do you see these people who do want to merge features from rbfx? There aren’t many, and I have no idea what the ratio is. But they are users of Urho too.

You are right, I will not argue with the poll.

If that is the best case scenario, then stay at rbfx and do not fix what is not broken here.

Because not everybody want what you want.
How would you react if people were trying to remove C# and WYSIWYG Editor for rfbx? Would you like that?
How hard is that to understand?

I don’t use C# anyway, so I wouldn’t care about it.

What exactly I’m trying to remove by adding more optimized, more powerful and more supported containers in Urho?

If you want Urho to stay unchanged, why don’t you go to fork instead?
Why do you prevent Urho master branch from developement?
Who gave you the right to decide for whole community?

And before you reply “who gave me right to decide”, care to quote exact place where I’m deciding anything, or else I will declare you a liar.

Clearly @Eugene cares about Urho too.

I don’t think this is true, now or ever.

@Eugene & @adhoc99 You both seem to be stuck in an all-or-nothing paradigm, repeatedly leading to a quarrel without substance.

I think the best idea at this point is to stop engaging with this adhoc99 individual. It’s not really productive to argue with a non-contributing anon troll who doesn’t really speak for anyone. Let the poll stand for awhile, gather some input from cooler heads, and see which way the winds blow.

My message indeed was phrased bad.
The best case scenario we get good things in Urho from or not from rbfx and keep them relatively close.
The good scenario is completely unchanging Urho and developing rbfx — in this case we may not care about painful merges from Urho (no changes, no merging)
The bad scenario is Urho getting minor and average features that rbfx will have to painfully merge.
The worst scenario is Urho and rbfx both actively developed and completely diverged.

This is my personal and biased point of view, not the global state of things.

Again, I disagree. To me this seems like one of the best possible scenarios. Each engine filling its niche and progressing. It would have been nice if rbfx were indeed developed as an experimental branch of Urho. Sadly the implications of this voiced purpose seem to have received little to no thought along the way, and now the incompatibility has grown to be cumbersome. Which is alright; rbfx went its own way and has gained value to exist in its own right. And so another great engine was born, but it is not for me.

You disagree with my personal biased opinion? I don’t think I’m surprised.

What’s the point of “experimental” if new things are not tested along the way? Sometimes you just cannot make isolated change.

Why don’t you stay on your fork instead?

Who gave you the right to decide?

Yes. This is an argument about directions. Except one direction is a U-turn and rolls over the other.

By the looks of it, it is pretty clear these changes will be pushed down regardless anyway. Which is what happens when a ship has no captain.

Becoming another want-to-be Unity will be so great. This time it will be a success for sure.

Now I know everything I need to know. You either don’t read my messages or are incapable of understanding them.

Since you are incapable of reasoned discussion, I’m ignoring you from now on.

If this doesn’t show the nightmare that development will be for those that disagree on direction, nothing will.

Things should be tested in any case. But I think - for an experimental branch - the iteration frequency of communicating and merging back to Urho has simply been too low, and with it the ties have broken.

@adhoc99 Don’t worry, I’m sure we’ll find a solution you too can live with.

What changes exactly? Nobody is suggesting to rebrand rbfx as Urho3D. Indeed the setup of this thread is broad and vague, but let’s aim for clarity instead of obstinance.

Unfortunately I am not very optimistic.

These (from the very first post of this thread):

But that is exactly what will end up happening in practice once Urho Containers and AS are gone, opening the way for merging C# and their Editor. Once those are in, how will this not be de facto Urbfxho3D?

In the end this fork as been done because Urho felt too restrictive, as far as I can see. Returning back, are you sure you won’t be stuck in the same situation again? What if you grow tired, or encounter problems (as it’s already happening just in this thread), and decide to leave again?

The problem is that you broke the line. It’s not a matter of features, tech or whatever. It a matter of trust.
So the question we have to answer is: do we trust these guys?
What do you think?

I too oppose the removal of AS, the addition of C# and have no interest in the rbfx editor. @cadaver once said that the editor should probably be kept in a separate repository and use a native GUI, and I agree.
This does not mean rbfx has nothing to offer in terms of saving effort, but the same is true for other engines and libraries.

Now, after reading so many replies, I think I quit talking and feel happy with Urho’s containers and other small parts. The whole engine is very unified internally and externally. In practical dirty commercial developing world, people care more about what can an engine provide, if they don’t like some part of the engine, they just stop using it in their own part of code. I’m writing code based on Urho in my very limited spare time and feel good about it.

Urho is designed to be lightweight, so keep it lightweight. It is beginner friendly. There are lots of game engines there, people can pick one of them or just choose rbfx. If someone really wants to improve it, take a part which is more like to be an obstacle. e.g. the rendering code. There are messy in the implementation, and not very feature powerful if you compare to other game engine.

There are more important things to fix, preventing Urho from a game maker! I’m talking about tasks like releasing games on Steam, iOS, Android, even consoles. Let me give you an example. Cocos2d-x. It is a lightweight game engine but people fixed it to be a ready to use game engine and build tools around it. Guess what, many excellent mobile titles are made by it and people get whatever they want.

And to fix rendering code we may need to make breaking changes more significant than containers.
Urho renderer is very rigid, but if you just add more flexibility in the joints it may start losing performance.
Maybe there is magical way to make everything great without breaking anything, but I’m not aware of one.

Nobody has proposed to never again make any breaking changes to Urho.

You know why I’m starting to feel pessimistic?

People here are not ready to accept EASTL even if change of containers is purely cosmetic for end user. I mean, end user will not lose any features, they will just need to patch their names.

How can they accept actual feature cut in renderer?
And I have no idea how to improve renderer without cutting bits that are 15 years old and harm more than help. For example, zones. Discrete zones cannot support smooth transitions, therefore they are useless for making nice looking picture. And I’m not talking about aaa pbr whatever, it affects all 3D with non-trivial lighting.

    /// Recalculate the ambient gradient colors from neighbor zones. Not safe to call from worker threads due to octree query.
    void UpdateAmbientGradient();

Oh, I know this one. I tried to refactor editor twice, you know?
Sure, you can get simple linear transition between two colors within the box.
It will help you render perfectly smooth gradient corridor between uniformly light room and uniformly dark room.
How can it help in real scenes, not ones synthetically build for this feature?
And keep in mind that transition should be quite long, or you will get light popping when object is transferred from or to gradient zone.

We must all accept our lord and savior EASTL.
Stop resisting it, just accept it as unconditional truth.

I don’t really get you’re resistance against EASTL and what would that harm you @adhoc99. Do you actually lose anything ?

Of course, you can make an extra-heavy engine, but who will use it? Who will ceate an AAA project with a multi-million budget on this engine? Who will risk big money and rely on a project that supports a small community? Urho3D is unique in that it is the best engine in its niche. Why do we need PBR rendering and raytracing in a game where the model consists of 14 polygons?

In no particular order:

1. It gets in, it opens the door for C# and that Editor next.
2. Urho Containers work well enough.
3. Who knows how many problems and bugs will come with that change.
4. EA.

1. I agree about C#, but I’m not against it. Let people use it. By doing it you attract bad and good attention. The good attention attracts devs… Editor needs revisiting, its working but its a bit outdated.
2. That never stopped me from refactoring code and I always made it better
3. You can check out EASTL development, it has issues but its working great.
4. I know man, I agree but …just because EA is behind it doesn’t mean its bad.

Can anyone plz tell why the fork happend in the first place?
Was it (how @johnnycable said) because urho main-devs are too restrictive?
What was the problem exactly? I can’t imagine they would have ignored ‘new feature’ pull-requests
if it was implemented the urho-way (I’m no power user and actually don’t know how difficult it is, to get a pull-request accepted, but I guess they had ‘stablity before features’ in mind (I’m guessing))

So the question is, are the problems that lead to the fork still valid? I guess yes, right?
If rbfx-people would ‘diverge back’ into urho again wouldn’t that just lead to the next conflict in no time?
I personally hate conflicts that don’t need to be. The decission to fork was as right back then as it is now.
You can go your own way with a great codebase and go in your own speed with your own restrictions. Would coming back make anyone happier?

And I guess noone is really against breaking changes in Urho, if they come from within. But it is like this:
A 3rd party wants and demands changes to come back. I personally really don’t care about if we use Urho3d’s Containersystem or EASTL, but it is this situation that make me suspicious. “We come, we want and we will obviously keep wanting other things afterwards…”
I say keep the trouble out of the house even if it costs you some features or faster progress…

Are you joining adhoc in ignoring my messages when answering on them?..
I hope not.

Do you seriously think that only AAA projects needs decent lighting?
Ever considerer 3D indie projects? Uhro renderer is outdated even for 3D indie.

This. Why do we need PBR rendering when 90% of indie games don’t have the budget to support an art team capable of producing assets that actually make good use of PBR? Why do we need Vulkan or a “better” renderer? It looks like yak shaving to me. Programming for the sake of programming and having the best state of the art codebase.

Urho is awesome because it is useful. It has the tools to help us make games. I can spin up a beautiful PBR “engine” in a month. But it won’t have usable animation, terrain, particles, audio, physics, scripting, IK, UI and all of the other hard stuff that Urho provides and that I actually need to create something. And Urho does it perfectly because it doesn’t get in my way. It’s like a framework, not an engine.

I apologize if I missed any answers. But it makes me feel that everything is bad in Urho. Containers are bad. Scripts are bad. Rendering is bad. Can you say that in Urho is good and why participate in a project where everything is bad.

1. Yes, it will definitely attact more devs, but I guess more (a lot more) bad than good ones. Once there are a lot of them then someone could say “C# is so popular, we should focus all development on that and also add a Unity-like Editor because all these C# devs want that!”. Can you see my concern with this slippery slope, escalation and permanent change of direction?

2. True, but that is improving it, not replacing it.

3. I still believe that if it is not broken, do not fix.

4. I am sorry, but it is not possible to ever trust a company with such history. Very few companies have such amazing achievements.

It happened because

1. PRs in build system were declined or abandoned or whatever I don’t really remember… But this part is not really important now.
2. Manual script bindings are pain in the ass to maintain.
3. Urho is generally more conservative and in fork it is possible to experiment with breaking changes.

Nobody is going to diverge back.
This topis is an offer of contribution.
And, considering reaction here, I’m starting to regret making this offer.

Urho is good. I mean, I just like it. /shrugs/

Not bad. Just outdated. Sometimes it’s fine. Sometimes I wish it had more.

Because indie project made on Unity with all default settings and that has just 10 colored boxes looks significantly better than you can ever make Urho look.
Why Urho loses in graphics quality even if you have scene of just 10 colored boxes?
It is genuinely makes me sad because I want to use Urho (because I don’t like C# at all I am C++ developer dammit!) but I also want… you know, graphics not from y2000?
I’m doing my best to change that, but that’s slow process.

There is this amazing project named rbfx.
It is awesome and has everything you are asking for.
You should definitely check it out.

Technology helps but doesn’t replace artists

Valve’s Source engine without PBR:

The opposite is also true. Sometimes lack of technology cannot be fixed by any amount of artists.

PBR may not be important, but global Illumination and gamma correction are.
And before you point me to gamma correction shader in Urho — no, it’s not how gamma correction is implemented. Gamma correction is not post process.

In Google work guys who constantly change the interface of YouTube. Because otherwise they will not be paid a salary. Why throw away what works. I do not know them, but I hate them.

Perhaps my point of view seems blurry. I am not against progress, you can change containers, add C# (I often use C# myself, just look my github, but I will by no means use it in games, because I see disgusting examples of freezing games on Unity). Just leave me the scripts. I need them and I stand for this only.

I think we made a full circle. One of primary reasons for fork was to get away from writing bindings manually.

Will there be a console in your engine? Are you planning to write your own interpreter? Do you think that you will do better than the author of AS?

Not sure what you mean saying “console”. I ported urho UI console to imgui. It wouldn’t be hard to add code to execute c# script directly from console either.

Thus, I do not understand what advantages I will gain from the changes, but I clearly see what I am losing.

Ok, I really think rbfx has its merits and a very clear direction. That is great for them.

Maybe all it needs is a bit of promotion so more people know about it.

These are honest suggestions to help rbfx be more popular (in no particular order):

1. Release a cool demo or game using it.
   Nothing showcases an engine better than a demo.
   I remember seeing NinjaSnowWar and thinking “ok, this engine can do it”.

2. Create an Youtube channel and make videos about it.
   Maybe some basic usage of the Editor so people that are used to other Engines can get on it quickly.
   Also some demos of what rbfx can do, like the lightmapper mentioned.

3. Make samples in C#.
   Those help a lot newcomers since C# seens to be the focus of rbfx.

4. Post about it on Reddit.
   If people like it, it will spread fast.
   If people do not, at least you will get some important feedback.

5. Create an index at rbfx.github.io.
   So people can find news, updates, samples and the documentation there.

Valve worked a lot on QuakeEngine and GoldSrc became its own thing and that worked out great for them.
I really think rbfx should do the same.

I want to say it for a record.
I don’t like C# as the only script option because it’s not truly part of the engine but chimeric augmentation on top of it.
It would be nice to have scripts with auto bindings that work within native core.
I don’t need them, but I’d like to have them anyway.

We already talked about this. I am all for re-adding lua bindings (swig-based). It all boils down to time constraints though. This is definitely on our wishlist, but there are other priorities first.

According to my memory @rku wanted C# in Urho, @cadaver (and others) opposed. Hence the rebel in the working title; it is a taunt to the throne. After that rbfx was marketed by @rku as the experimental branch of Urho, which drew some more developers his way. As mentioned before I don’t believe it deserves that title any longer, if ever.

I don’t understand this “ownership” attitude. Urho is not owned by anyone. It is free and open source software. It belongs to all. If rbfx wants to call itself an experimental branch of Urho, they can. Freedom.

I think it was me promoting as experimental fork, no?
Why it does not deserve this title?
It is a fork of Urho, technically. Philosophical questions aside.
It shares the core with Urho, even if said core is slightly changed.
And it is definitely experimental.
What of two words do you disagree with?

A branch is not the same as a fork. When applying the word branch to a fork it implies a connection, which has not been maintained in the case of rbfx.

I miss Lasse so much. Now more than ever.
This ship really needs its captain.
Wish he was here, even if only as BDFL and nothing else.

And who knows when the King himself will be reincarnated

I agree on this one.

Open source project cannot be driven by democracy, since there always will be people with different vision.

It would be great if you did not mislead people. Thank you very much.

Fork happened because I:

• Wanted a proper build system
• A useful profiler
• Not to deal with manual bindings

C# was an experiment that turned out well enough. It never was my primary concern. Neither was editor. So when people ask what I wanted to do be so kind and do not act as my secretary. Also that question was already answered in the thread.

Edit: general attitude seems as if I’m trying to sell heroin (c#) to the kids and therefore I must be hated. Please just stop that already…

I think it’s a unfair to call current build system ”improper”.
It just has long history. Projects with reach legacy often reach this state when they appear bloated and full of weird complexities.

Let’s say you want simpler build system.

I wonder how many developers will be able to see they have been tricked by a vanity troll.

Please, without insults

I still cannot understand why, if rbfx is so awesome there, they want so much to change things here.

I admire the level he reached with the artform, but it is dispicable nonetheless.

We don’t. @rku never wanted it and I offered it here because Urho sorely lack contributions.

Then please, for the love of Urho, stay on rbfx.
You guys can be the BDFL there and go unopposed on the direction you so desire.

@adhoc99 What? Why?
@Eugene Welcome back!

As I said earlier, Urho can not compete in graphics quality even with simplest 3D indie games as soon as it comes to lighting.

I’m trying to change that and part of my work have been already “released” in rbfx.

I thought that Urho may be interested in moving in this direction and created this thread. Supposedly, I’ve mistaken. Or maybe I’m not. Dunno.

I believe the focus of Urho should be lightweight performance, meaning relatively little to clone and build plus running fast on ageing hardware and fit for more than just games. Pretty modern day graphics are great to have as a capability, but the mere capability itself should not slow down simpler setups or unnecessarily introduce fat libraries.

As I said before, sometimes the line between “lightweight” and “missing features” is very thin.
In my optinion, “lightweight” means that it is small and it can be extended on demand shall the need arise. While “missing features” means that is is small, but it also cannot be extended in case of need, at least not without significant effort. You see, size may be the same, but the scope of use cases is wastly different.

This:

Urho does not have to be UE4.
If it slowly inches forward, let it slowly go.

And exactly because so much is optional - but not part of core - I think Urho could benefit greatly from an extension exchange environment. Someday this could be woven into some convenient modular engine assembler that connects to a community-maintained repository of sorts (full of free components and other extra features) dependencies and all, but it might not be this decade.

Pay attention to the poll results, not some vocal argumentative minority. Let the poll ride for awhile, see where the actual community sits. It’s easy to get angry and get the wrong takeaway. One guy doesn’t speak for entire community.

Also note that a great deal of voters that do not care about AS already use rbfx.
Which makes me wonder: What is wrong with rbfx?

I made a mistake making poll. Can always subtract extra people from “don’t care” option. Anyway, these polls are just to keep track of people attitudes. This is not a vote.

Maybe rbfx needs a forum?

You mean it is not binding, the forum calls it votes.

And an index on the rbfx.github.io for news, links to samples and documentation.
It would help a lot to have a game or demo to showcase it.
And a youtube channel to help promote it.

Indeed, also the logo could be better.

I don’t know if this is still valid: https://free.discourse.group/
Maybe they could ask the guys @discourse

I find it very odd how people are against increasing the visual fidelity of lighting in Urho. As time goes by, certain baseline expectations come into being. Things like PBR aren’t just passing fads that can be safely ignored because they’re ‘too hard’ to use, they’re increasingly taking over the discussion around lighting and asset creation. Without even attempting to meet those minimum expectations, Urho3D becomes a crusty old relic that the majority will pass over by default because it simply doesn’t meet their minimum expectations. I have decreased my own efforts of promotion for Urho3D in the various communities I inhabit, simply because more and more the devs I know want the support of a strong PBR pipeline. That alone should be at least a minimum capability of any engine that purports to be relevant today.

At this point, I can’t see 1.8 ever being finished, much less any Urho3D 2.0 project seeing completion. There are a lot of half-baked ideas for asset browsers and community building, but they’re empty shells with few prospects of turning into anything relevant or useful if development progress on the engine itself remains stagnant. Dead engine is dead. At least if these changes that the rbfx devs have introduced are merged upstream, there is a chance that some of the things being done in rbfx can be ported over as well. But the further from base rbfx gets, the harder that becomes.

The core devs are gone. @cadaver isn’t coming back, @weitjong has some pretty serious problems to deal with currently, and has already indicated in the past an inclination to step away from the project. On number of commits done, @Eugene has been among the largest contributor to vanilla, but apparently some individuals would rather he not make any more contributions. So who’s left that is actually doing things? Anyone? I see a lot of half-completed PRs, unsolved issues, empty recent commit history, and a whole lot of agitating for status quo. These aren’t signs of a healthy project, in my mind.

Even though I tinker with rbfx, I still have projects based in vanilla. My current active project is vanilla, and my terrain editor is still vanilla, though I do have a local rbfx-based branch that appears likely to become the master. Goblinson Crusoe is still vanilla-based. I don’t want to see vanilla remain dead. I’d rather have to spend a few days refactoring to meet the changes from rbfx, than see the engine fall further and further into irrelevancy like so many of my past favorites have done.

Do you use scripting languages in your projects?

Yes, I use Lua. But you know what? Scripting language support already is pretty broken. A) It makes it difficult to merge PRs. Someone tries to do a new thing, but if they don’t also do script bindings for it, it doesn’t get merged. B) Lua scripting is broken. tolua++ has issues that have brought up years ago (ie https://github.com/urho3d/Urho3D/issues/649 ) for how Urho objects returned by value from bound functions can greatly grow the size of internal tables if not carefully managed. tolua++ itself is an obsolete and unsupported project, that isn’t even keeping up with the language standard. So it’ll be a hard sell for you to convince me we should maintain the status quo, when the status quo is already a somewhat broken mess. Automated binding generation would go a LONG way toward solving some of these issues, which is part of what the rbfx devs were hoping to accomplish.

AS works for me, I can even change the source code of the editor without restarting it

@JTippetts Have you tried AngelScript?

Or could move early to rbfx. Given the similarities, could spend some days refactoring to use rbfx instead.

It looks like that updates will probably be more frequent there anyway.

Yes. AS still has the issue of if you don’t write bindings for it, it doesn’t get merged. If it does get merged, AS becomes obsolete. Someone still has to maintain those script bindings if they’re not automatically generated, but that maintenance has to occur whether or not changes are merged from rbfx. Again, automatic script binding generation would go a LONG way toward solving some issues, and that was a stated objective of the rbfx devs.

This already was the consensus before they left.

That may be, but between the Urho core devs and the rbfx core devs, which group has actually been working on it and making progress toward it? And we’re supposed to just automatically discount the possibility of making use of that progress, for reasons.

Nobody is stopping anyone from using rbfx, AngelScript is appreciated around here.

Yet I have a question. You said you were using rbfx. What language do you write your applications?

Ok, I’m very late to this conversation: What is the purpose of this question? What point is it that getting an answer to this question will get across?

I am trying to understand why a person who writes in a scripting language is trying to deprive all users of the ability to write in scripting languages.

I suppose this thread is now officially longest thread in Urho history \o/
Where’s my badge? There must be one.

That’s not their point (from what I have read)
Angelscript is hell to support because of the way bindings are generated is what I’ve been able to gather.
If there was a project to get autogenerated bindings with AngleScript I’m sure they’d support it.

There is no off-topic badge.

If you cannot write bindings manually, should it be deleted?

A pity.
Although this thread is much less off topic than you imply. Most of the posts are on topic, it’s just the topic too wide.

It’s just that it’s horrible to maintain, and it’s extra work that doesn’t have to be done.

This is a strong argument. Sorry for using AS and that I can bind my functions if I need.

Sadly, due to time constrains, I cannot contribute to urho or rbfx.
But as a user of urho, I can tell you what would make rbfx or a different fork attractive to me:

• Unified shaders
• Metal support (maybe Vulkan too)
• Compute shaders
• General renderpath definition
• Better asset pipeline (maybe)

Different script binding, PBR, different containers, are very nice to have, but they are not limiting factors. One can implement any of them if they need to.
I don’t think making urho more like Unity (C#, nice editor) will make it more attractive. Unity and Godot offer that already.
If a urho fork can offer at least some of this, it will make the switch very attractive.

To urho developers:
Don’t get me wrong, I love this engine, but maintaining two (maybe three if metal gets added) versions of my shaders is a big issue for me. Lacking compute shaders, metal support and full renderpath control limits what I can do with the engine. Current asset pipeline it’s not a deal breaker, but has many limitations.

I want a unified shader language too.

I expect that to be another point which most of us would agree on. Just like automated script bindings. Although I stuck to OpenGL-only so far, so no pressure as far as I’m concerned.

A very valid usecase. I eventually plan to polish build system enough to allow users easily plug binding generation into build process so they can have their game classes wrapped automatically by adding few lines of cmake and a trivial SWIG interface. And automatic beats manual.

ek/unified-shaders

WIP in the editor.

Nobody is “making urho like unity”. If i wanted unity, i would use unity. I want ease of use of unity with flexibility of urho3d. Which means that you can use it however you want. There is no need to talk as if placing objects in the scene using a gizmo is some kind of sin. C# is great as a scripting language. It has a rich ecosystem around it, terrific tools. Heck you can debug C# plugins right from visual studio. That also is not a sin.

Maybe a day will come when you start thinking about more than one person.

And you know, everyone acts as if we are here to take away your legacy v1. Branch we merely extended our hand and offered our free time to help make v2 happen while v1 can remain in maintenance mode as it has been for a good while to be honest. Something like ogre2. So this is a chance at having Urho3D v2.0. What will happen now is either community takes it and has a fighting chance or declines it and Urho3D forever remains as it is today. Some people are already migrating. The better rbfx gets - the worse Urho3D will look in comparison. Gap will widen more and more. There will be a point when editor is no longer heavily WIP and actually usable. Then we will promote it a little, just to put it next to Urho3D in google search. And when people do a comparison it will be nobrainer which project they should chose. rbfx commit history is a proof we can do it, and this friendly discussion encourages my evil genius to work hard towards that end.

What i do not understand is why people are trying to turn us into a hostile fork when we are trying to be a friendly fork.

I must mention that unified shaders in this branch are not even remotely ready. It’s just a confirmation that unified shaders are possible.

And more importantly - high on our TODO list.

Actually we have different ideas about scripting languages. You must compile a C# source as a Dll and connect it to a project in one of the ways as a plugin. This is not how the scripting language works. Or you can compile on the fly using the built-in compiler, load the compiled code, which in turn will load the rest of the engine libraries in a separate context, try to somehow take data from this context and transfer it to the main engine. This is in order to execute a single command in the console.

Could you clarify what you mean here? In rbfx everything is loaded in same AppDomain so data sharing is trivial. Also if you are interacting with scripting - all the .NET stuff is loaded already (that is how i made it anyway). Hot-reload is implemented using good old data serialization. I did explore using different AppDomains for scripting and that proved to be a nightmare for data sharing. Not that it was impossible, but it is a can of worms. Having everything in same AppDomain is just so much simpler and easier. Yes, we still have a problem where each code reload pollutes process memory with unused .NET libraries that are not unloaded. However .NET core 3+ has API for unloading them. We will eventually make use of that. There are many rough edges that need polishing, i do not deny it. But i do honestly believe C# as it is now in rbfx is almost as good as current bindings and even better in some other areas.

I suppose @1vanK just shares the same view on scripting as me.
That scripting core should be compact submodule of the engine like physics or scene, not something that operates on process and module level.

I guess you mean the fact that building with C# makes main executable a .NET exe? I agree with you there. It is just a shortcut to support multiple .NET runtimes without writing runtime-specific code. No reason we can not have a native executable host .NET runtime. People often dislike .NET runtime due to it’s size. It is way more fat than lua, there is no denying. But we are not distributing anything on floppy disks nowdays so size is hardly relevant. I totally understand personal preferences, choosing lua over C#. That is fine. Maybe eventually we can offer automated bindings for lua as well

I am not a developer Urho, although I am not indifferent.
There is a suggestion for the community.

Since there is no leader as such (but everyone has their own contribution to the engine), I propose voting like this (change the calculation as you wish) depending on the place https://github.com/urho3d/Urho3D/graphs/contributors points are calculated for the voter, for example Kadavr has 1 place = 100 (total number of participants) -1 (place) = 99, weitjong 98 (100-2), etc. according to the results of voting, for example, be EAstl: yes or no, the sum of the votes of the voters is compared.
It does not matter if the current account or not - the order remains. If not in the list of developers, you can earn 1 point.

Any voting, at the same time you need to keep at least 3 (N?) Days on the forum, voting begins (you never know who will change their mind from someone’s reasoned arguments and change their mind)

Disputes take a lot of time and effort, sometimes you need cold-bloodedness

Raw plan, I propose to vote)

It’s not about the size of the files. C# free memory when RAM ends. Take any game on Unity. At first it works fast and well. Then it eats up all the memory and constantly starts “stop the world”. Writing in C # is easy and enjoyable, but writing good code is much more complicated than in C ++. Because it is a constant struggle with the garbage collector, which is under the hood.

I have an idea. Just make auto bind AScript and lua. Then wrap all existing function calls for backward compatibility. Update rendering stuff. Then make this version 2… Then everyone will be happy. Who is the expert of auto binding?

By the way, C# is not that bad compared to java. It is actually great.

I would love to see co routine being added.

Great idea. You have our support. Do it

I don’t really believe that this kind of question can really be solved by vote and calculation. Especially considering how unreliable and volatile this “contribution” metric is.

Oh wow I see Lasse typing. Gonna be interesting. Or not. Who knows?

It’s just a shame when newcomers or observers categorically may not respect the opinions of direct engine veterans. You must always remember - without you there would be no engine. To hell, modesty is your brainchild!)

Some thoughts, I’m not even going to discussion of features but just the development speed and community structure.

Rbfx is doing great work. It’s basically leadership by coding, and having a minimal community that isn’t a burden. That is something to cherish. Trying to bring things back to Urho, and dealing with Urho community when you have minimal resources, is inevitably inertia.

Now my question is more to Urho community, in which ways would it have to change, and which requirements would you have to relax so that someone of you would want to step up as a lead and set the direction of the Urho codebase as going forward? It may be an impossible question, in which case it’s probably best that both forks work on their own.

Whoever the new leader will be, there will always be dissenters who simply leave. Because the community arose around a leader who had his own vision of the engine.Save the community is possible only with the old leader

Let me remind that the “vision” was to learn game rendering techniques of circa. 2010, learn doing game engine lowlevel things, not to crash like Ogre, and not to choke on small batch count like Ogre. Without having a concrete usecase. That can not carry forever

@cadaver please, return as a BDFL, even if it is only to be casting vote. The ship needs its captain. Urho3D needs you, even if it is just to point the direction and nothing else.

No, I was too glad to get away. You must decide what you want, I don’t want to have a say in that.

Eventually I will want to have a new tiny, near-100% NIH codebase for rendering and engine experiments again, and I can’t forbid anyone taking inspiration if that happens (though it’s unlikely), but so far I’ve been busy with retro game development.

Pass the throne or something then…)
not to me) and then here is anarchy

As an free and open source game development cult, LucKey Productions is reluctant to support spyware while looking to reward people that make the right choices.

Well, I am passionate about Urho3D and have a clear vision for its future that respects its nature. I would by no means be a replacement for @cadaver, but I do have other skills that could propagate the engine further and would be willing to listen to engine and game developers alike when the path to take is not clear.

Please don’t treat this message as personal insult or attack, but as an honest inquiry.

How can a person who doesn’t develop a project have a vision of future development of said project?
https://github.com/urho3d/Urho3D/pulls?utf8=✓&q=+is%3Apr+author%3AModanung+
I don’t know of any your contributions, except making this nice new logo. And I failed to find any, except few small patches.
Maybe I missed something?

As to why I raised this topic…
You see, at my current day job all project managers and architects were coders before they were promoted into new position, and they still code (albeit less) in their new positions because otherwise they will lose a touch.

In open source this is especially important because a person with a vision have to implement all or significant part of this vision.

I have seen talks about community components for years, and you have confirmed in this thread that this is part of your vision, but I don’t see it done, even after all these years.

If you see a way here, please tell, because I don’t.

I vote for @Modanung
He has been here for ages.
He is patient and helps constantly on this forum.
When a newcomer appear here he is usually the first in line to greet and help.
I believe he is also one of the people that released most games with Urho3D.
We do not need Carmack or Torvalds on the helm.
A project is much more than just raw code.

CEOs do not have to be programmers, yet they can lead a software company. Indeed I have more experience using Urho to create games and software (including editors) than workin on the engine itself. In part because I feel I am simply not ready for the latter task in many cases. Also some of my engine contributions did not make it into the statistics due to the merging process.
Productivity can also come from cooperation, agreeing on near and long term goals helps remedy expectations of one’s efforts being futile. Also we must not ignore things like @dertom’s work; the engine code does not have to change for Urho to become more powerful. People are working to improve the engine and its environment even though it does not show up in the contribution statistics.

rbfx would benefit greatly if @Modanung is a new leader. I vote for @Modanung.

Urho is not a company, and you don’t hire developers to enforce your vision of the project.

I know only two ways how to make a software. Either the leader is developer (like Lasse was), or the leader is hiring developers.
You are neither, as far as I know. How do you plan to deliver functional improvements into the project? For example community components.

I obviously don’t argue that community management is important on its own. I just don’t see how it is connected to development of the project.

It was a comparison, not an equation. What I meant to say is that the leader does not have to be lead engine developer, this could be a separate position.

Now I’m confused.
Can you please elaborate how it works?

Lead developer can enforce their vision and shape the project into what they want.

Community leader may have some vision too, but they still don’t have any power to enforce said vision unless lead developer shares this vision and is willing to enforce it.

It all boils down to lead developer driving the project with their vision and vision of community leader is completely irrelevant (even tho it may be taken into consideration)

The only thing worst than no leader is two leaders.

Even @rku agrees that the best for rbfx would be @Modanung.

Since you support rbfx so much, how can you disagree with that?

Only because he would drive project into the ground and Urho3D is no longer a competitor. You clearly don’t read between the lines.

I agree.

I also think that open source project without paid positions cannot be led by non-developer.
If you disagree, prove me wrong. At least one example of open source programming framework led by non-developer. Then I will believe.

I am no specialist, but I believe my diverse skill set is advantageous for coordination.

In an open source project developers are a part of the community. Ideally a project leader leads both development and community, but this is merely the natural state in every beginning and a rare luxury after that.

Good! Let Urho3D be.
I am amazed why are you even here since rbfx is so much better.

Oh, maybe this guy: https://www.zdnet.com/article/linus-torvalds-im-not-a-programmer-anymore/

Yeah.

Lol wat. He is developer, just former. You just made counter-example you know?
That before you become a leader, you have to become really good developer.

Sorry, I miss a lot of context because I rarely read this forum.
Can you please give me an example of functional improvement in Urho you have coordinated?
I know about logo, it is really cool one, but it’s too simple example. And not functional.

Btw…the 2 times I made contributions here I forgot to do Lua or AS bindings and my PRs were getting stuck for a long time waiting for a merge. I’m not using Urho3D for anything shiny, its not even a game, so AS/Lua has no value for me…although its always nice to run my app with “–editor” flag and it turns on as Editor alongside all my code. The best thing about the engine for me is it (almost) run out of the box on every platform I need (35$ android box or RPI). If you can have an option to keep it that way, maybe a set of flags turning off mono/C# scripting, disable fancy PBR stuff and heavy (for low-end devices) rendering, I don’t see why not experiment with new stuff.

How can you ask me to show results of the very task at hand? Most collaboration where coordination on my part was involved had to do with LucKey Productions.

"I don’t know coding at all anymore. Most of the code I write is in my e-mails. So somebody sends me a patch … I [reply with] pseudo code. I’m so used to editing patches now I sometimes edit patches and send out the patch without having ever tested it. I literally wrote it in the mail and say, ‘I think this is how it should be done,’ but this is what I do, I am not a programmer. "

No no, I think this is PRETTY clear.
Unless you think you know more about Linus than Linus himself.

Yeah, because all projects start with people that already know everything that has to be know. No open source project ever started with anyone learning on the way.

This is some kind of senseless dispute, Linus Torvalds would never lead a project if he not programmed it

But that is exactly what he is doing now. By his own words. He became a manager basically. And the kernel is doing great.

The discussion was clearly at an impasse. and now the question is how to save you in peace

Because he does not have time for programming

He said he is not a programmer. I.e. he doesn’t write code to commit.
He explicitly said he works with code, he knows it, he reads it and he can write it. Therefore he is developer. I don’t see where he says “no, I’m not developer and I have never been one, I’m community manager”

Only if you even read the article: "In short, these days Torvalds is a code manager and maintainer, not a developer. That’s fine with him: “I see one of my primary goals to be very responsive when people send me patches. I want to be like, I say yes or no within a day or two. During a merge, the day or two may stretch into a week, but I want to be there all the time as a maintainer.” "

But keep going trying to find an angle. This is hilarious.

@Eugene My hands may not have been drowned in grease, but the purpose of an engine is to serve as part of a vehicle.

You are just trying to twist the words so they fit your position.
“He is not a developer” means he is not participating in active development. Bet the very next words are “maintainer”, and maintenance is something that software developers do.
Therefore he is software developer. That’s what he can write in his CV.

I see one of my primary goals to be very responsive when people send me patches. I want to be like, I say yes or no within a day or two.

Oh look, a C# path. Nope.
Oh look, a bug fix. Yep.

Hey guys, we need John Carmack for this.

Am I not a software developer?

How can you review a patch if you have no clue about what the code do?

That is so arrongant.
Like you are the only one capable of even reading a patch and testing it to see it works.

In fact, I propose making Modanung the Linux project leader (and on weekends adhoc99)

p.s. should we split this topic or will we break the record?

Why would you want to kill linux?

I don’t know /shrugs/
If you are, I don’t see your contributions in the Urho codebase.
I have no idea how much do you know about internals of said codebase and its architecture.

I think you are software developer since you make projects and you can write code. However, I have no means to measure your expertise with Urho specifically.

Why aren’t you on rbfx forum again? Oh wait…

Let’s keep this topic. This is probably the biggest activity on the forum ever.

Yeah, good job starting World War Urho.

Did you see this thread?

While this drama was raging rbfx got 5 new commits and Urho3D got @adhoc99. This topic is amazing.

rbfx is that way >>>

Nope. Told ya, I missed a lot.
Are there any results there? See only GPL discussion so far.

I honestly didn’t mean it this way xD
Just wanted to try and push lightmapper into Urho, asked people what do they think…

I’m just a recent new member of this community so don’t have much weight in saying. But imo if EASTL or just std containers are to replace existing Urho containers, maybe marking the old ones as deprecated so old code or code from people using old containers can still work.
I think there are a lot of people out there having their own forks of Urho3d, maybe not ready to merge to main repo yet, and some of them might be using Urho3d containers. If the new containers completely replace the old ones, it would create problems for those ppl.
We don’t need to keep deprecated containers forever. Maybe plan to completely remove them in far future or in a totally new version (like Ogre next)

I do apologize for not being very productive through my latest chapter of great stress, depression and displacement.

Totally know that feeling. I Spent year contributing nothing because was too depressed.

You are one huge pillar of this community.
Every thread I read you are there, helping, supporting.
Your contribution and dedication to Urho3D is priceless.

Come on @Modanung are we back to hiding posts you do not like?

That attitude is exactly why were resisting so hard against this proposal and rbfx.

I urge everyone not to talk about personalities

I think @Miegamicis would make a great lead developer, btw.
Or should I say archchancellor?

I vote for @1vanK
He also have been here for a long time.
He has a lot of contributions.
He clearly knows the engine.
He doesn’t even have to be 100% active, just be the casting vote.

Oh no I’m not competent enough

Just be the compass for this ship.

I like him too.
But I will repeat myself. Only a person who actually work with code and write the code is capable of driving development of the project.
There is no point in envisioning a feature if you cannot bring it to existence.
Your vision may go only so far as your abilities.
For example, I don’t enforce any vision on rbfx build system or C# scrips, because it is outside of my knowledge and I cannot actually do anything there.

And why the Leader can’t ask for help if needed?

Because leader is the one who is usually asked to help, not vice versa. Who can Leader ask if there are no people who can answer?

If leader cannot do their job properly without assistance of outsiders, how can such person be really called leader?

All open source libraries known to me have developer leaders.
And Linus is developer too (In the sense that he can work with code) — development is not only about committing code.

I’ve been lurking for quite a while but I had to register just to comment because this thread is fascinating. First, I have to ask - @adhoc99, what do you expect to get out of this thread? You’re only derailing the topic, twisting other people’s words, and putting forward either pointless arguments (I particularly love the Linus one tbh), or saying “why don’t you go away then”, as if that would solve anything.

Now, a bit more ontopic, I think it’s hard to argue that Urho3D has seen a steep decline in commits and contributors in general. Stagnation in the 3d engine space is normally pretty bad for adoption, so it seems reasonable to assume that it’ll be a vicious cycle and eventually kill it unless something changes. rbfx on the other hand does have the commits and contributors and the energy, but perhaps lacking a solid community platform (forum, etc). To me, it seems pretty reasonable that there would be some sort of a merge (if not complete, at least partial), and this thread seems to be constantly deviating from that point.

Re: leadership without development
I think it’s definitely not the best option. In open source, having a vision and only being able to put that vision forward by making others do it for you seems like a recipe for disaster, as people are volunteering after all. It’d also make it harder to have clear visibility on technical debt, pain points, feature complexity, take decisions on architectural design, etc. It’s probably possible, it’s just impractical - it makes everything harder than it should be, while also introducing additional overhead.

–

Lastly, I imagine everyone who voted [against] in the poll has a proposal of how the future for Urho should look like, including who will be carrying out those changes? I went to count and there have been barely 10 commits or so that are not toolchain commits in the last ~2 months. And they are mostly small fixes. That seems a lot like how a maintenance branch would look, so I personally don’t understand the strong pusback to calling it like Urho 2.0 and moving forward. I guess the dealbreaker here will indeed be whether a solid leadership behind Urho forms that can steer the ship one way or the other.

I want to know if this will become rbfx?

Maybe the question instead is why rbfx is coming HERE?

The leader, above all else, sets a direction.

Leader of open source project, above all else, does most of the work in development.
If you disagree, find at lease one counterexample.
Not Linus, who wrote god knows how much code before he stopped.

This is essentially saying “i will be the ideas guy and you do all the boring work”. Yes that works out well.

Is this not the difference between a leader and a lone wolf?

A more fitting candidate may arise in the future. Who knows, maybe Urho will be in a state that @cadaver regains sufficient interest at his convenience.
Also, welcome to the forums!

When leader cannot guarantee they will have a pack that will support them (I.e. by hiring people), the leader should be capable of being lone wolf. IIRC this is exactly what Lasse was when starting Urho

@Eugene How much did you look into LucKey Productions?

Never seen the repo. See it now. Don’t see how it is related to my previous post.

This is not just adding new cool features. It is about throwing away existing functionality. Why do we need two identical repositories? Is it bad when people have a choice?

It is how I have familiarized myself with the engine and auxiliary workflow without simultaneously having to bother with script bindings, traffic lights, the risk of screwing things up or increasing the workload of other people.
I never said I’m perfect.

I admit that you are experienced user of Urho.
What will you do if you are asked to make changes in the engine?
Lasse was asked this all the time. By me too.

For example, I want gamma correction.
Can you add it? Or can you point out to me what should I do to add it myself?
Or I need networking in Web builds. What should I do to get it?

This is what kind of questions are asked to a person in charge of a project.
I receive it from time to time in rbfx gitter.
Just yesterday got whole set of questions like “I want X”

provides a clear example of that
Oh not that one.

When people are sufficiently motivated and gregarious it can be enough to know who to invite into the conversation, which I think is the essence of coordination.

Did you just say that Linus is the leader who never contributed to the project he is leading?

What part of https://www.zdnet.com/article/linus-torvalds-im-not-a-programmer-anymore/ is hard to understand?

I have thought about that but am a bit uncertain that I would be a great fit for this role. I’m not really an expert in this field, gamedev has been my passion for the last decade, but it’s just a hobby.

What part of this article says that Linus never contributed to the project he manages?

Oh he contributes, but no longer as being a programmer. He just says yes or no to stop anyone from rocking the boat.

Thank you very much.
I know a lot of examples of people who were project developers and then became project managers.
I know such people personally, at my dayjob.

How about you answer my question, and not the question you imagined for yourself?
There is specific scenario. A person who is not a project developer want to become project manager.
Do you know any example of such thing happening in open-source libraries/projects before? Without money involved, mind you. For money you can buy everything.

And if you cannot see the difference between “project developer” -> “project manager” and “NOT project developer” -> “project manager”, I don’t think I can make you see it.

Maybe we should approach this from different angle.

@Modanung say you are new BDFL. Whats your plan to make urho great again? How will you persuade people to implement your vision?

For someone fighting so hard to get this proposal through, while you could just continue on rbfx and do whatever you wanted there, why don’t you just say you want to be the Chief here.

I will answer this when you give me an example of “NOT project developer” → “project manager” in open-source. If you are ignoring inconvinient questions, I can do it too.

One thing i learned over the years on the internet is that people who want to be leaders often are poor ones. Good leaders on the other hand never want that position because they understand weight of it. This is why i said in another thread that i do not want a community. It is a big responsibility, a commitment that can not be made lightly. Just writing code is easy.

Would it make more sense to you if LucKey Productions adopted Urho3D? Most commercial engines are part of a game studio.

@rku Urho is great, but it can always be greater.

This sound very controversially and I can imagine people twisting these words.

Oh yeah, go ahead.
Hide everything.
Proves my point perfectly.

If this adoption means full-time employment, I can imagine a lot of people standing in the line to get it.
If not, what functionality will Urho get from such adoption?

Come on. As an aspiring leader you should have at least a rough idea of the plan. So please do not dodge a question. I honestly do not see how you are going to make people implement your idea without paying them salary.

Things might make more sense to you in that configuration.

I see it more as volunteering than aspiring. My goal is making games, not engines.

The main problem is that we’re all just users here, and nobody wants to, or is qualified to, step up and do the engine dev. @rku and @Eugene are doing that for rbfx, but nobody wants to do it here. Dead engine is dead.

Leave that up to the necromancer.

@adhoc99 should be banned for flagging stuff he does not like. I think we had enough of that persona.

Doesn’t Urho3D already have gamma correction but most shaders don’t use it?
PostProcess.glsl contains functions for applying and inversing gamma and PBR albedo textures are sampled with srgb gamma applied if I understand correctly but the engine is not inversing the final output by default. Sorry for being off topic. Just wanted to ask because I might missunderstand gamma correction. Especially when it comes to PBR.

Ask the person flagging my posts.

Nope, it wasn’t him, it was me.
Wanted to know how flags work, sorry for inconvinience.
I was wondering if a person flagged see flagging immediatelly or after confirmation.
I added comment to flag explaining this, not sure if you can see that.

Welcome to the forums!

Well well, should not that be banned then?

You are positing off-topic since the start of the thread and deserve your flaging.

It means “doen’t support”.
If I cannot open samples and enable gamma correction without rewriting shaders, it’s not supported.

So does you. So does he.

I flagged your posts. The off-topic flagging tools are there for a reason, and in this thread you are that reason. I have seen very little from you that was on-topic or useful to this discussion.

Then we should flag your post too for being off-topic, right?

You are the sole responsible for this.
For example @1vanK may not agree with me in many aspects, but he is reasonable person doing resonable discussion.
You are trowing shit on the fan. Leith, isn’t you? !voteban

Absolutely. Because it is off-topic. I’ll be exiting this discussion, now. I’ve seen all there is to see here, I think.

Oh yeah. I am sure you want to ban me.
Proves my point perfectly and shows the nightmare this project will be for people that disagree.

Ladies and gentlemen, I’m afraid it is closing time.