BerconTile for RT GPU, when?

[3LP]

Hi guys,
I just wanted to know if you guys have any plans or ETA or at least some kind information about when BerconTiles support in RT GPU.

As we progress in time, GPU is more and more used in production and it starts to be really hard to by pass the use of bercon maps into production or really heavily time consuming to achieve the same results using different techniques.

When would this be available please?

Thanks
Stan

[svetlozar.draganov]

We have it as a feature request into our system already but we are not able to provide ETA so far.

[Moriah]

Any update on this? BerconTile is really powerful... Nothing on Vray 3.45.01

[svetlozar.draganov]

We are sorry to report but BerconTile is not supported yet.

[tricky]

Is it a difficult thing to code RT GPU to use BerconTile?

Would it be easier for Chaosgroup to write their own plugin? I'd happily pay for that plugin.

[benb32]

Sorry if this post doesn't answer your question directly - but without digressing too far I hope to create a summary, Vlado and Blago feel free to correct me if I'm way off in my interpretation.

I think the Chaos guys are at a crossroads with supporting both BerconMaps and tiles (plus a lot other plugins)... writing support for lots of plugins creates dependencies and increases the kernel size of the RT code. I know Vlado and Blago have been doing a ton of work to recode the RT kernel to make it more modular (helping the AMD cards with open cl) and allowing the kernel to dynamically only include the specific parts needed for rendering a scene. I'm guessing this work has lead to the perception of the RT development appearing to move more slowly than the Adv renderer. Howvever, Multitile support has been included as a feature now.

After a plugin has been added and tested it needs to be ported to the other environments too. I can speculate that there are a lot of significant differences between all the environments that slows things down. Take for example how Max and Maya both treat bump mapping differently. This is why there are still differences between the Adv and RT engines in production. As an alternative method, some things that are more difficult/performance expensive for the GPU are pre calculated on the CPU and then transferred to the GPU after - I'm most looking forward to Blago's work to stream textures and assets to the GPU memory as needed (but I would imagine with real world memory latency not having changed in the last 10 years and bandwith limitations, it is not as quick as they would hope).

From memory Vlado would like to guide things more towards OSL. That way there is no need to port plugins once they have been created and tested. The OSL code runs quite quickly too. There was mention of an intern at Chaos recoding some of the bercon stuff to work with OSL.

Personally I'm so grateful for everything the Chaos team give and the superb product they've created that keeps getting better!

[Rens]

A basic tile shader should be very easy to make in OSL. I'll have a look at that.

[savage309]

Bercon maps are really not well suited for GPU rendering ... but the demand for them is quite high, so probably we have to think of something.

Best,
Blago.

[kosso_olli]

Bercon maps are really not well suited for GPU rendering ... but the demand for them is quite high, so probably we have to think of something..

The main advantage for using Bercon noise for example is the variety of noise modes and the distortion feature. If there is anything similar that is supported by RT GPU, I would be glad to switch.

[benb32]

I agree absolutely... the main features for me are bercon noise, forest colour and making the bump mapping congruent between the Adv and RT engines. As an afterthought, hoping Blago is looking into round edges and VRayStochasticFlakesMtl (I can dream... )

Trust, I realise that these are big asks and time is difficult to find. So many things come up and divert from the background progress ark that Chaos would like to follow - the denoiser being one feature, but, with hindsight is superb! And also the experimental AI shader that Vlado has been working on...

I'm expecting the bercon noise to find its support in RT by being implemented with OSL - maybe with collaboration with some of the brilliant scripters on this forum.

Guess forest colour will come directly from coding it in conjunction with itoo, due to its closeness with forest pack.

Know Blago will have a few tricks up his sleeve for the bump mapping.

With so many features and directions time and patience are needed.

[benb32]

A basic tile shader should be very easy to make in OSL. I'll have a look at that.

Brilliant! +1

Would work across all the environments Max and Maya. Some of the proceduals work by RT baking the texture and then passing the baked image to the GPU. Maybe this could be taken advantage of, not sure how dependant it is on the program environment though...

[Nicinus]

I've never used Bercon Tile and Crossmap, are there any advantages compared to multitexture and FloorGenerator?

[chriserskine]

the main use i have for bercon tile for is "center tile mapping"

its really good for doing paving with each tile being a solid colour.

the only other way i know to do this in 3dsmax is with forest colour. but I don't use that for paving.

otherwise it mean taking it to rhino/grasshopper.

[biochemical_animations]

I actually got Bercon Noise to work in GPU RT when putting inside a TriPlanar Texture. I didn't test all scenarios tho, and I'm not sure it matches up with a CPU render, but it worked for me.

[Sbrusse]

I've never used Bercon Tile and Crossmap, are there any advantages compared to multitexture and FloorGenerator?

Crossmap is waaaaay more advance.
We ditched multitexture like 4 years ago already to work exclusively with crossmap.
Once you tried it, you can't get back to multitexture

It's definitely the number one constrain for us along side wall&tiles who is just a plug that uses bercon and crossmap at the same time.