13 comments

[ 3.8 ms ] story [ 24.1 ms ] thread
It would be great to have VR support for something like this. The field of VR content creation is woefully sparse.
The github page sounds like there might be experimental support. There are instructions to build a windows VR version. I could not find much more information about it though.
Congratulations to the team, it looks extremely impressive!

(Disclaimer: this isn't an area I know anything about.)

Amazing. I can see this project completely destroy substance painter in a couple of years.
I like the idea of the material editor being part of the product. It would make a much better workflow for Substance; it gets repetitive exporting from Designer to Painter.
Lubos Lenco the author behind this is something of a one man army. They also write Armory 3D a game engine that integrates with Blender https://armory3d.org/

Fun fact, ArmorPaint is written in haxe which is still a relatively niche language but well worth a look into for building cross-platform apps

Haxe seems to have some impressive accomplishments for how obscure it seems to be. Several games I've heard of and play.
Just a question about English, why is it "physically based", as in "physically based rendering", instead of "physics based"? To me it sounds like "physically" should be followed by some other word than "based", like "physically correct". But yet it's used this way.
Well, the rendering is not really "physics based". This would imply some sort of first-principles formulation, and you see those only in some renderers.

Rendering algorithms are more like an artistic bag of tricks. The "physically based" implies the tricks are approximating the visual acuity of realistic scenes with physics inspired approximations and the like.

PBR algorithms tend to at least start from the rendering equation and simplify/approximate from that. They attempt to maintain some semblance of accuracy by eg. employing the conservation of energy of emitted vs. received light of every point of the scene; or expressing matte texture by the statistical behaviour microfacets of a rough surface; or using actual radiometry/photometry units to express lighting elements of the scene; making the scene also be expressed in concrete real-world units, ... There's still a lot of cheating and smoke and mirrors, but at least all these operate from the idea that the math should check out.

This is in contrast to more oldschool approaches that were fully dependent on tweaking things until they looked right - ie., taking blinn-phong in a scene with some 'ambient lighting' and operating in fully imaginary units, modified by an artist on scene-by-scene basis.

Because while it's inspired by physics, it's usually a limited model that's not 100% physically accurate. "Physically based rendering" doesn't have to include photon mapping, for instance, which means caustics won't be visible (without some other way of cheating them into place, anyway).
You're right, you would say tomato based soup and not tomato-y based soup. ...but english is not that rigorous and names stick.
Licensed as zlib/png, but binaries are currently €16. It looks like the Unreal integration is being funded in part by a grant from Epic Games.

Interesting to see an open source project in this traditionally high-end boutique market. I think comparable tools include BodyPaint 3D ($995), Substance Painter ($150+), 3DCoat ($99+), and maybe ZBrush ($895) and Mudbox ($7-10 / month).

When I see what textures look like, independent of the model, it's hard to imagine creating them without some kind of painting interface like this.