Improvements to Physically Based Rendering

[Illes Papp]

The Physically Based Rendering Experimental Feature is improved with the following new features:

1. Procedural Sky - The newly introduced Procedural Sky generates a sky dome with an accurately positioned Sun disc which affects not only the background but also the lighting of the scene.
2. Shadow Mapping - Shadow mapping produces much faster results than shadow volumes, with soft shadow edges.
3. Automatic Exposure Control and Bloom Effect - Exposure is automatically controlled, similar to real life cameras. High luminance regions generate a so called “blooming“ effect.
4. Improved Ambient Occlusion - Previously certain areas of 3D scenes introduced some artifacts, and with the improvements these are not appearing any more (available from Archicad 27 Update 2).

For more details, please read the following reference:
Visualization - Graphisoft Community

Looking forward to having your much appreciated feedbacks, questions and insights.

[abdelaziz]

I would just like to know if the Physically Based Rendering development could impact our documents in the future (Section, elevation, Ducument 3d......) ? it is this type of document that needs to be improved, for example having the ambient occlusion on an elevation

The simplest would be to directly retrieve the development of the ALLPLAN viewport 

[strangeday]

Hello @abdelaziz , I completely agree with you, at present it is not too useful, but if they think to make it available in all views, in particular 3d document, that nowadays seems come directly from '90🤣(in this regard I would already be happy, if we could place 3D views onto layout, directly with a good definition in terms of DPI and the edge of the element antialiased!!), and finally make possible a sort of standardization of the graphic output of the different views, it could became a very interesting project,

clearly as @torben_wadlinger says it should not be considered as a rendering tool, because it can never be compared to specific rendering software, and honestly, probably due to my lack of experience on the subject, both cinerender and redshift could be removed from my point of view, because the first is really outdated, difficult to setup, and quite slow compared to solutions today present on the market(that in some cases are also free as blender+cycles, or twinmotion), and the second seems not maintained, and after the integration in AC25 haven't received structural update, so the long list of limitations has not changed during the years, and the last update of the core features(such us the compatibility with AMD videocard) has never reached archicad users

[abdelaziz]

Hi,@Illes Papp

Would it be possible in the final version of your physics engine to have the same visual effects of the U-RENDER engine which no longer exists today, it has not had a buyer

https://www.youtube.com/watch?v=cdwHvBHwTcE

[Jim Allen]

You are missing the point I think. This is going to be an option for a visual display styles - just like the others, and that I think is welcome. Once the GI colour bleeding with shadows is fixed and tonemapping for the background is implemented, it will be useful for many of us.

Bolting the render code onto the display engine won't (and clearly didn't) take years of development. First of all it shouldn't break anything, secondly it needs almost no documentation.

It's a bit like the AI renderer which basically bolted a front end UI onto a Midjourney conduit. Not hugely demanding in terms of coding, and not a core feature needing extensive and exhaustive testing.

[Jim Allen]

No - Torben is misunderstanding the point of this tool.

It is not a render tool - it's a display style, and as has been explained, will be migrated to that part of the interface in a subsequent release.

It was never intended to be a render tool. It's purely an additional option for model display based on a more realistic shaded view.

It simply works based on the materials settings in the hardware acceleration preview. You don't need the complex surface/materials configuration parameters for the render engine.

In that regard - I think it's a useful improvement, or will be when the tonemapping is fixed...

[Jim Allen]

There are lots of render engines available for use.

I spent over 10 years working on a renderer which integrated the Kray render engine into SketchUp, so I know quite a bit about this stuff.

There's the ease of geometry translation, how it handles materials, the camera view options, scene description configuration, physical sky implementation, support for things like background environments, light types, HDRI, licensing requirements, ease of configuration, feature list and speed.

I distilled the Kray interface into a very simplified form and configured one click render presets.

There's a lot of work in this, and then there's the suitability of the basic AC 3D engine to deal with high poly counts in the model,  the best way of dealing with this is to use geometry proxies.

GS absolutely do not want to be integrating this into Archicad. It's a BIM application not a renderer.

If a high quality render engine was built right in, you need higher quality assets to populate your model, which increases the polygon count significantly and makes models very unwieldy to navigate. I once downloaded a 3D mixer tap from BIMObject which had more polygons than the rest of my model. And people are stupid when they use this stuff. I've seen models stuffed with really bad high polygon count 3D Warehouse content that are difficult to use. 

It also takes a long time to design the interface and functionality.

That's why it's much easier to integrate links to external standalone applications. It also reduces the overhead on support and documentation. 

Twinmotion is an excellent option in this regard. You keep all your non-construction related assets in your visualisation model and deal with configuration there.

Archicad stays clean and the GS team can focus on core design, construction and production documentation features.

Suggestions of alternative render engines to use are missing the point.

This is nothing more than a fancy display style that we ought to be able to use instead of the other options where suitable.

[thesleepofreason]

---

---

That it will be implemented as a display options and not a "render tool" doesn't necessarily mean that the development isn't misguided and reading from the feature article "Archicad’s native Physically Based Rendering engine in 3D views ensures more realistic visualizations while you model - without having to create a rendering" I'm not convinced that this is not the case. 

Could a better rendering engine be generally useful for 3D modelling or for conveying abstract building information? Of course but it need to be developed with that in focus and not "realistic visualisations". Where is the development currently at - a buffed up detail shading option? And what is the goal? Could the resources be better spent in the same area? High resolution 3D capture, interactive and better sun/projection settings, proper 3D view management and enhanced cut and filter functionality would all have a much larger impact on core functionality (3D BIM modelling) and workflow efficiency. But perhaps it is as you said - easier to just bolt on some new code.

[strangeday]

Hi @Jim Allen , agree with you, my hope is only the possibility to see this 3d style, without this tedious bluish effect, also available for other type of representation  such as sections, elevations and 3d documents(and following this faq about AC28 Archicad 28 New Features Q&A - Graphisoft Community, seems that this could be an aurgument already known inside Graphisoft)

[Jim Allen]

I think a number of people are approaching this from the wrong angle and probably over-thinking it.

In the context of continuous improvement, the notion of a simple flat textured display is a bit noughties. The industry has moved on. 

SketchUp has and is steadily improving its 3D display options. It's part of a general migration towards more visually sophisticated ways of viewing models while working with them. So it makes sense for all 3D apps to do a similar thing to avoid being left behind.

Don't forget also that a 3d modelling environment also helps with design.

Graphisoft is simply evolving the 3d view options. As far as I can tell and based on the way things have been communicated anyway - I don't have any secret 'insider knowledge'.

This view style enhancement is likely a bolt-on of some code from elsewhere. All the shading and sky colour algorithms required for this type of display are open source and freely available. It's really common for students to code render engines as part of their degree or Masters courses.

I don't know if you have ever stumbled upon videos of Siggraph presentations, there are things there that will blow your mind, and a lot come from academic institutions. That's where a lot of the industry technology comes from.

So I'm absolutely certain this is not the result of months of painstaking development by a team. I suspect it's the work of a single person so concerns about eroding core development resources I personally think are likely to be misplaced.

I'm pretty sure it's little more than an enhancement to 3d display styles that's going to be embedded into our normal workflow.

But it definitely needs tonemapping options to be exposed for end user configuration...

[thesleepofreason]

---

@Jim Allen wrote:

So I'm absolutely certain this is not the result of months of painstaking development by a team. I suspect it's the work of a single person so concerns about eroding core development resources I personally think are likely to be misplaced.

If so - doesn't that just raise a lot of other concerns? So we have this small effort one person development as one of eight new features for AC28 while still after two releases not being completed and according to the Q&A not seem to be so in the near future (a lot of work for one person).

As said - I agree that a better engine would be generally useful both for modelling and conveying abstract building information. What strikes me as worrying is that GS seemed to start with a focus on "realistic visualisations" rather than getting the fundamentals in place.

How about contours in Physically Based Rendering?

We are currently researching this feature, and trying to locate performance and technology bottlenecks.

It is more complex than it seems to be, so it's difficult to say an ETA. We’ll come back with an answer later, but at the moment I cannot be more accurate than that.

Would it be possible to manage the transparency or intensity of shadows?

It is not possible at the moment (in Archicad 28), but I agree that finding a good default is important. Our current research is twofold: finding the best out-of-the box setting, and if necessary, providing an easy-to-use custom setting.

Is showing edge lines possible now with the physical rendering engine? Is it possible to save a picture with desired quality and resolution as a .png or .jpg without window resize?

These are highly requested features that are not available in Archicad 28 yet, but are currently actively being researched/tested.

Can we have these Physically Based Rendering effects in our 3D documents, sections, facades...?

As an experimental feature, Physically Based Rendering has its limitations -  for example it is not yet available as a 3D Style. Right now, when PBR is turned on, it takes over in your 3D views. 

Are you planning to introduce an engine setting in the Surface settings for the Physically Based Renderer as well?

There are plans to improve material representation in PBR. The difficulty is to harmonize surfaces through different visualization modes. The exact solution is under research.

Do you plan to use HDRImage ?

We are considering this possibility in the long term.