Stealing Panda3D's Render Pipeline


#1

The people with the right skills and time (sadly that’s not me on both accounts) might want to take a look at this:

It’s an awesome looking renderer (quality comparable to Unreal). It MIGHT be possible to adapt it for Urho3D, or at least “steal” some ideas. I don’t have the skills (nor the time) to tell how easy/hard it would be to modify it to work with Urho, but I thought (in my nativity) that it might be easier than writing something like that from scratch.


#2

It’s a straight rip of the UE4 code, I got into it ages ago, but it was and still is just copy-paste from UE4. Down to the exact enums, arg names, and switch statements on identical material codes bad.

Use at your own risk. You still owe Epic their % cut since no sane person will say it isn’t Epic’s property.

It’s like SpeedTree, you think you’re smart hijacking UE4’s stuff for it, you’re just going to get sued and lose.

Edit:

You’re doubly screwed though since my grievances with the Panda PBR pipeline document the issue and prove that you’re working with Epic’s work. I even have a private legacy fork of it should I need it to justify my asshole behaviour.

I will testify against you.


#3

That explains why it’s quality looks just like UE4.
If they use the same code then, yes, it’s not at good idea to use it (I thought someone came up with something original and just as good as UE4).

I wonder if Panda3D have any agreement with Epic, or will they just get in legal trouble as soon as they release version 1.10 !?


#4

Interesting. So it would be basically a stealing of a stealing… :open_mouth:
EDIT: what about this filament thing? Someone posted the link some time ago…
I tried it on Mac. OpenGL is ok, Vulkan renderer thru Molten is not.
Did someone try it on windows or linux? (oops)


#5

From what I’ve seen filament is awesome, and it shouldn’t be ripped code considering it’s affiliated with Google. (from what I understand at least)


#6

Although I do think this is reason to be suspicious/cautious, the license is compatible.


#7

The project is led by Philip Rideout, a.k.a the little grasshopper.
This guy seems to know its way about 3d.
The project is actively developed by Google (4 person I think), and is used in the Sceneform Android Library.
Apparently can be accessed in Android Studio with a plugin. Didn’t tried that.
It can be useful to substitute for a Metal renderer, and, in the long time, it’s probably the only viable option out of bgfx.


#8

Actually there is an engine i found iteresting. Xenko. What’s really interesting is that looks absolutely professional has all the tools , it’s crossplatform , supports all nexgen effects.Only thing i don’t like , it is written in C#… But what’s really amazing is that it is licensed under MIT ! Awesome ! Unity could be in trouble :smiley:

https://xenko.com/


#9

Pretty sure they only went open source because they couldn’t sell enough licenses. Could be totally wrong here though. Besides, that doesn’t really matter if the engine is any good.


#10

I had a brief look at Xenko a few months ago, and although it has a pretty looking renderer, I think it’s not much more than that. It has a very limited (non-existent) scene management, which means you can only have small scenes with limited number of objects (they have some kind of sub-scene streaming mechanism, but that only suitable for some kind of games). Also I don’t think they have a terrain, or networking. So, it might be a good start for something to be built on top of it.
Unity is not in trouble yet (at least not from Xenko).

In my experience I’m yet to find another free open-source engine that’s as well designed and overall functional as Urho3D. If we could get some global illumination and some post-processing shaders in its pipeline by default, it should be quite awesome.


#11

I’m working on a new-ish SSAO shader. One already exists from the community but I wasn’t happy with it. Will probably post that up when I feel it’s good enough. Some other cool post effects would also be nice, but I can’t think of any that aren’t very specific. Like a dithering shader. Pretty sure no one wants that unless they are making a VERY stylized game.


#12

I think a good SSAO shader with some bloom on top (which I think we already have) would go a long wait to improving the visual quality of the engine.


#13

I think some big issues lay more on the fault of the dev than the engine itself. A big issue I’m seeing is texture quality, and another is lighting. If those 2 things are fixed the engine could look passable without needing to change any code. That doesn’t mean there aren’t problems with the engine, of course. For instance, while it’s nice to have PBR Urho’s implementation of it isn’t the best looking. Far from ugly, but also far from AAA quality… Honestly I think a lot of the graphical issues could be fixed if someone knows their way around shaders.


#14

I agree with this. I have spent alot of time with other engines. I even used Irrlicht engine for 2 years. Although Irrlicht engine is easier to use I have been able to accomplish more with Urho3d than I did in months of using Irrlicht Engine.


#15

I feel like Urho3d is a good balance of good graphics, and other features. Many people just concentrate on graphics, but many games look great, and they still suck.


#16

The quality of the assets you use will certainly have an impact on the visual quality of the game and the engine cannot do much about that.

However, on the engine’s side of things, producing AAA quality is a combination of techniques, which include: good lighting (global illumination), PBR and post-processing (SSAO and bloom being the most significant). Having just one and not the others cannot compete with engines that have them all. But the technique that makes the most impact by itself (IMO), is actually SSAO, maybe even more that PBR, so I’m really looking forward to your implementation.


#17

I’m having a lot of trouble getting any variation of SSAO to work aside from the one that was already made. I tried modding that one to look better and I almost did it, but it still didn’t look right. One issue with the community implementation is that it changes based on viewing angle, which is ugly.


#18

Isn’t SSAO expected to change based on viewing angle, since it is Screen Space? From Wikipedia, it is “rather local and in many cases view-dependent, as it is dependent on adjacent texel depths which may be generated by any geometry whatsoever.” (I don’t really know anything about it beyond the basics, though, so I may misunderstand what you mean)


#19

IDK, maybe it IS supposed to do that… I should get a video of it, because it doesn’t look very good or intentional.


#20

It maybe an offtopic but I would like to bring BGFX to the conversation. It still sounds reasonable to use it for rendering abstraction but keep all the other code the same (render paths, etc).