Overhaul Proposal

Everything about the development of Urho3D.

Re: Overhaul Proposal

PostPosted by yushli » 20 Jun 2016, 12:50

@dragonCASTjosh, If you really have time and energy to begin the overhaul, please bring the newly added PBR feature to the next level first. Compare it to Unity's level of performance and feature richness. Then make a real world sample game using this PBR feature. It is hard to convince other people to use this feature if it is left half way to the product level of quality.
User avatar
yushli
Some active
Some active
 
Posts: 94
Joined: 18 Oct 2014, 05:42

Re: Overhaul Proposal

PostPosted by Enhex » 20 Jun 2016, 18:41

dragonCASTjosh wrote:
Enhex wrote: Material Prototypes
- Don't know what that means.

it is essentially inheritance for materials, for example a child material that just changes the diffuse color

Resource wise I'm not sure if it's a good idea - it will save some writing and will require less maintenance but will be more complex and inspecting materials will be harder because you'll have to track down base material files.
Programmatically it's possible to clone a material and do changes, that's what I do now when I have a base material with some variable parameter like color, which is easier to manage because there are no extra files to maintain, which also means faster loading.

dragonCASTjosh wrote:
Enhex wrote: Support for Code Plug-ins
- Not sure what you mean by plug-ins, but you can already use Urho as a C++ library and add whatever you want. And there's scripting.

I way for the community to write features that are not suitable for the main repo, yes you can make your own fork but that often means that the branch if behind. With plugins features like a new scripting language or new editor features could just be a small download the you can load into the engine or editor to get that feature.

You can write a C++ library on top of Urho without modifying it, so other users just need to include it. Personally I've wrote several libs that way even for internal use to avoid forking and allow reuse.
For example topic1895.html

dragonCASTjosh wrote:
Enhex wrote: Hand written documentation
- Already exists

Most of the current documentation is generated from comments in the source, my idea was to go through and create documentation for everything by hand including code examples (look at unity and unreal for reference). i know this would take allot of time and would be an ongoing project but it feel it would be beneficial

You have http://urho3d.github.io/documentation/HEAD/index.html (a complete list: http://urho3d.github.io/documentation/HEAD/pages.html)
The comments are hand written, and you got the samples for code examples.
I don't see where the problem is, did you run into specific cases where the documentation wasn't enough? If so those specific cases should be fixed.

dragonCASTjosh wrote:
Enhex wrote: Updated UI textures
- What updating means? Better default ones?

I mean a fresh coat of paint to make the editor look higher quality, higher resolution with effects like highlights and shadow in the texture.

So better default. I'm for, but I'm not sure if it should have high priority.
User avatar
Enhex
Most active user
Most active user
 
Posts: 325
Joined: 31 Dec 2014, 12:23

Re: Overhaul Proposal

PostPosted by Bluemoon » 20 Jun 2016, 20:22

If its for UI makeover then I'm 100% in support. I feel the UI needs a bit of work to be done on it.
Was even starting up a lightweight pet project to uses HTML/CSS/JS for UI so I can integrate it into Urho3D. If the project gains much traction I will definitely forward it as a UI proposal
Every complex thing is made up of simple parts
User avatar
Bluemoon
Active user
Active user
 
Posts: 108
Joined: 23 May 2014, 09:42
Location: Nigeria

Re: Overhaul Proposal

PostPosted by cadaver » 20 Jun 2016, 21:08

namic wrote:About the unified shading language: there's no need to reinvent the wheel with https://github.com/bkaradzic/bgfx around.

It is a working solution yes, but not something I'd call particularly elegant, or necessarily a "final" solution. It's based on macro / preprocessor transformations, and though it's based on GLSL it forces you to use non-idiomatic expressions, like doing matrix multiplication with a mul() function so it translates easily to HLSL. That's not necessarily bad, as long as the rules are clearly known, but there's room to search for even better solutions.
User avatar
cadaver
Urho3D author
Urho3D author
 
Posts: 1802
Joined: 16 Jan 2014, 14:52
Location: Finland

Re: Overhaul Proposal

PostPosted by Enhex » 20 Jun 2016, 21:30

Regarding unified shading language:
There's a C++ library for OpenCL called VexCL which uses expression templates (with Boost.Proto) to compile C++ code to OpenCL/CUDA code.
I believe a similar thing can be done with GLSL & HLSL.
User avatar
Enhex
Most active user
Most active user
 
Posts: 325
Joined: 31 Dec 2014, 12:23

Re: Overhaul Proposal

PostPosted by hd_ » 21 Jun 2016, 00:31

Enhex wrote:
dragonCASTjosh wrote:
Enhex wrote: Material Prototypes
- Don't know what that means.

it is essentially inheritance for materials, for example a child material that just changes the diffuse color

Resource wise I'm not sure if it's a good idea - it will save some writing and will require less maintenance but will be more complex and inspecting materials will be harder because you'll have to track down base material files.
Programmatically it's possible to clone a material and do changes, that's what I do now when I have a base material with some variable parameter like color, which is easier to manage because there are no extra files to maintain, which also means faster loading.


Material inheritance is a pretty cool feature well demonstrated in UE4 (although in UE4 it's a must considering how long shader recompilation takes).

In this issue, weitjong mentions that it should be possible to use material inheritance already: https://github.com/urho3d/Urho3D/issues ... t-86881286

Exposing this to the editor would be the ideal scenario.
User avatar
hd_
Contributor
Contributor
 
Posts: 220
Joined: 21 Jul 2014, 08:55
Location: Australia

Re: Overhaul Proposal

PostPosted by dragonCASTjosh » 21 Jun 2016, 10:31

yushli wrote:@dragonCASTjosh, If you really have time and energy to begin the overhaul, please bring the newly added PBR feature to the next level first. Compare it to Unity's level of performance and feature richness. Then make a real world sample game using this PBR feature. It is hard to convince other people to use this feature if it is left half way to the product level of quality.


I actually have this finished for D3D11 although you will need to filter the cubemap outside the engine for the best results. all i need is to port it to OpenGL before i merge it. you can download a D3D11 demo here https://drive.google.com/file/d/0B7EwsKWU8ATkclZnM0NhUEIyU1E/view

hd_ wrote:Material inheritance is a pretty cool feature well demonstrated in UE4 (although in UE4 it's a must considering how long shader recompilation takes).In this issue, weitjong mentions that it should be possible to use material inheritance already: https://github.com/urho3d/Urho3D/issues ... t-86881286Exposing this to the editor would be the ideal scenario.

I shall look into weitjong's suggestion and see how well it performs.

cadaver wrote:namic wrote:About the unified shading language: there's no need to reinvent the wheel with https://github.com/bkaradzic/bgfx around.It is a working solution yes, but not something I'd call particularly elegant, or necessarily a "final" solution. It's based on macro / preprocessor transformations, and though it's based on GLSL it forces you to use non-idiomatic expressions, like doing matrix multiplication with a mul() function so it translates easily to HLSL. That's not necessarily bad, as long as the rules are clearly known, but there's room to search for even better solutions.

I did consider BGFX for more then just the shaders, it has a strong rendering abstraction but I'm not sure if its the best approach.

Enhex wrote:You can write a C++ library on top of Urho without modifying it, so other users just need to include it. Personally I've wrote several libs that way even for internal use to avoid forking and allow reuse. For example topic1895.html

My issue with it is that it wont doesn't integrate with the editor, for example the terrain editor that the community made requires a separate executable rather then integrating with the existing editor


Enhex wrote:You have http://urho3d.github.io/documentation/HEAD/index.html (a complete list: http://urho3d.github.io/documentation/HEAD/pages.html)The comments are hand written, and you got the samples for code examples.I don't see where the problem is, did you run into specific cases where the documentation wasn't enough? If so those specific cases should be fixed.

My issue with it is when you go to learn the Scripting API you only have comments to work from for the most part, if there was a group effort to go through and remove all dependency on comments by hand writing it in detail including examples for everything, this would be an on going effort.
User avatar
dragonCASTjosh
Moderator
Moderator
 
Posts: 205
Joined: 04 Aug 2015, 18:59

Re: Overhaul Proposal

PostPosted by cadaver » 21 Jun 2016, 10:58

Plugins by themselves don't solve integration to the (current) editor. As it's a self-standing AngelScript application which cannot be accessed well from the outside (either C++ or Lua), the terrain editor would still need to be AngelScript too to integrate well, and to use the same UI / view system as the rest of the editor.

It's a different story if you are going to do a full C++ editor overhaul, and define an API for how plugins attach to the editor.

Plugins would be immediately beneficial if the only thing you need to do is to define extra components that you want to appear editable. Currently you'd need to construct a custom Urho3DPlayer that integrates your custom code (which adds things) and then runs the editor script.
User avatar
cadaver
Urho3D author
Urho3D author
 
Posts: 1802
Joined: 16 Jan 2014, 14:52
Location: Finland

Re: Overhaul Proposal

PostPosted by dragonCASTjosh » 21 Jun 2016, 11:05

cadaver wrote:Plugins by themselves don't solve integration to the (current) editor. As it's a self-standing AngelScript application which cannot be accessed well from the outside (either C++ or Lua), the terrain editor would still need to be AngelScript too to integrate well, and to use the same UI / view system as the rest of the editor.

It's a different story if you are going to do a full C++ editor overhaul, and define an API for how plugins attach to the editor.

Plugins would be immediately beneficial if the only thing you need to do is to define extra components that you want to appear editable. Currently you'd need to construct a custom Urho3DPlayer that integrates your custom code (which adds things) and then runs the editor script.

I would likely move the editor over to C++, that way the editor and the player are separate programs and the editor can launch the game for testing.
User avatar
dragonCASTjosh
Moderator
Moderator
 
Posts: 205
Joined: 04 Aug 2015, 18:59

Re: Overhaul Proposal

PostPosted by cadaver » 21 Jun 2016, 11:21

You don't need different executables for that really. You could just as well launch Urho3DPlayer from the editor again, with a parameter that runs the game script.

However I've spoken of this before, Urho is defined to be just a library, so there is not really a universal concept of how you "launch the game", as that can vary from project to project, or may not even make sense in some projects.
User avatar
cadaver
Urho3D author
Urho3D author
 
Posts: 1802
Joined: 16 Jan 2014, 14:52
Location: Finland

PreviousNext

Return to Developer Talk

Who is online

Users browsing this forum: No registered users and 0 guests

cron