[Brendan Sharp]

I first read something on this subject in a slightly older post and thought it would be a good topic to clear up in a quick post hence the title.

In the latest version of maxwell V 2.5.11 nurbs surfaces within blocks, with emitter materials applied, appear to cause lots of noise in rendered image...

Can emitter materials be used in block instances at all?

If not... could this be a possible update facility for future versions.......

cheers.

[JDHill]

I can see why it may be confusing, because things are always being worked on and changing. In this case it will make a big difference if you are using one of the release preview (2.5.1 & 2.5.11) plugins or not. Here's why:

• Maxwell Render does not support emitters on instances. It never has, and the plugin can do nothing to change this.
• plugins versioned 2.5.0 and earlier addressed this limitation by refusing to export any emitter material on an instance; it would go out with the default material, and an error would be printed in the plugin log.
• plugin versions 2.5.1 & 2.5.11 take a different approach. When they encounter an instance which has an emitter, they just export it as normal geometry.

Therefore, the contention that 'emitters assigned to blocks' can affect anything is a false one; since Maxwell itself has never rendered an emitter on an instance, any difference in performance must be ascribed to the total number of emitter objects being used, which may be much higher if you are using plugin 2.5.1 or 2.5.11.

To sum up then, and knowing that you are using plugin 2.5.11, I will go point by point:

In the latest version of maxwell V 2.5.11 nurbs surfaces within blocks, with emitter materials applied, appear to cause lots of noise in rendered image...

Noise is a function of rendering speed. Rendering speed is affected by the total number of emitter objects in your scene. In plugins 2.5.0 and older, emitters assigned to blocks could not affect rendering speed, since those blocks would be exported with no emitter material. In plugin 2.5.1 though, this changes, and the question of block/non-block becomes irrelevant. Any difference in rendering speed must be due to the total number of emitter objects being exported, regardless whether they come from normal geometry, or from a block.

There is a secondary point here, regarding the use of NURBS objects as emitter geometry. If you use NURBS as emitter geometry, you should make sure that you are optimizing the meshing of that geometry using Object Properties > Custom Render Mesh > Adjust, in order to minimize the complexity of the generated render mesh, since the complexity of an emitter object affects its rendering performance; complex emitter meshes take longer to render than simpler ones.

Can emitter materials be used in block instances at all?

If not... could this be a possible update facility for future versions.......

Hopefully this question has been answered by the above. Maxwell Render does not support instances, but plugins 2.5.1 and 2.5.11 auto-convert what otherwise would have been instances into real geometry. Therefore, the most accurate statement would be: emitter materials cannot be used on instances in Maxwell, but using plugins 2.5.1 and 2.5.11, they may be used on blocks in Rhino.

[kami]

Hi JD
I got a question around blocks:
I use them quite often lately since it has become very comfortable with rhino5s block edit. the only thing bothering me is the texturing. with real scale you can very easy assign textures to the different objects (by layer assignment usually) or when editing the block you can assign materials by object and even apply box mapping for the objects. there's only one thing I'd like to be able to do:
I've become a great fan of the randomize textures-plugin you wrote which helps a lot against a too cg-ish look of the images. If I got several objects copied as blocks I have to explode them to be able to randomize the mappings or even to apply a contingous box mapping for all of them, is this right? There can't be an easier way or a possibility to keep the block assignment active?
Thanks for the info.
Cheers, kami

[JDHill]

I'm not sure I understand. Say that you take a cube, texture it, block it, and then make a copy of the blocked cube. So, in the export, you will get one mesh cube and one instance of that mesh cube. What point could there be then in randomizing textures on the two blocks? As I say, I must be misunderstanding -- could you reduce the question to a clear, specific scenario?

[Brendan Sharp]

Hi Jeremy thanks for your reply, this clears up any uncertainty about emitters in blocks regarding the various versions.

here is the problem I am encountering. I have an open motorway desert scene, (which does not help things) with many lights. (something like 790 lampost blocks- some double, some single lights) giving a total of 1074 surfaces within the model with an emmitter material assigned to them. These surfaces are simple planes having tried the steps you recomended- custom render mesh settings using simple controls reducing the compexity of the mesh to the lowest setting. They are therefore a simple geometry made up of only 2 triangles each. I also have another layer with 1074 native lights at my desposal.

to speed up and reduce complexity of maxwells output I hid many of them that were out of the focal scene leaving only 234 visable.

Now rendering with this with the layer that the emitter surfaces are on- turned off renders fine 'and quickly'!
Turning them on produces a fair bit of noise evident even in the preview image from the start.
I have toyed around with all manner of circumstances eg. turning layes off, changing materials etc for many weeks along with your help, thanks.....
One case i tried was tuning off the emitter materials and instead activating another layer which holds native lights in their place. 2 things about this; I stand by the fact that I am able to direct light more efficiently as downlighters with this method so would love to use them in conjunction with the emitter surfaces eventually where the emitters would represent the yellow glow of the bulbs/natives to spotlight the pavement.
When turning on the natives with show sun in viewport and use sun in physical sky setting checked, the whole viewport scene darkens and render output changes overall colour to less vibrant though fairly realistic.

I have let all renders run for about 11 hours each to sL 21. (1- just with emitter surfaces (2- just with native lights & (3- with both .... and still noise on all! I know this could be the shear amount of emitter materials I have in total, but I need to create these night motorway scenes where illumated elements are key for a light sculptue eventually. Any Ideas if you could suggest steps for me to send you the file you could check it out, far to big for my hotmail e mail. and too big for 'you send it'. I know you use winscp but that thing baffles me..... thanks in advance.

[JDHill]

Firstly, I'll just note that you could cut the number of emitter triangles in half by using a single triangle instead of two. That said, your recurring comment about that native lights rendering faster than hand-optimized low-poly mesh planes does make me think of one possible factor though: when you use native lights, an individual emitter material is created for each light; that's probably not the case when you are using hand-built emitter geometry -- you probably assign a single emitter to many objects. Maybe there is an engine optimization lurking in the details here -- I'll mention it to the core developers.

When turning on the natives with show sun in viewport and use sun in physical sky setting checked, the whole viewport scene darkens...

You do not have to use the Show Sun in Viewport function; it does not affect the render. It only puts a directional light in the Rhino viewport to help you pre-visualize where the sun is located. If you don't like the way Rhino displays your scene with that directional light included, the solution is simply not use Show Sun in Viewport.

I have let all renders run for about 11 hours each to sL 21. (1- just with emitter surfaces (2- just with native lights & (3- with both .... and still noise on all! I know this could be the shear amount of emitter materials I have in total, but I need to create these night motorway scenes where illumated elements are key for a light sculptue eventually. Any Ideas if you could suggest steps for me to send you the file you could check it out, far to big for my hotmail e mail. and too big for 'you send it'. I know you use winscp but that thing baffles me..... thanks in advance.

Sorry, but I really have to try to keep my support confined to specifically plugin-related issues, i.e. bugs in the plugin, and not general Maxwell usage questions. My instinct is to say that you are rendering a quite demanding scene; it is a nighttime shot, with hundreds or thousands of emitters; it is simply going to take alot of processing power. Keep in mind that unless you intend on using multilight for presentation, or because you actually need to save images with different versions of lighting, that you can gain some speed by turning it off, and also by adding the -nomxi argument to Output > Export > Command-line; that way, you are telling Maxwell that it doesn't have to write huge MXI files to your disk all the time.

[kami]

Sorry for capturing the thread, I guess I'd better have started a new one ...

The export as instances is not really important for me since I usually disable instances. But I use blocks for smaller file size and for more flexibility on changing parts of a building.


What I am trying to achieve is the look in the upper part and the only thing I achieve to get with blocks is the part below. Is there any possibility to have a bunch of blocks which have the same geometry but are individually textured?

Also what I said about real scale and block objects: Sadly it does not work. The realscale feature is never applied to an object inside a block, not even if I hit RestoreViewport. Is this something that could be fixed? I used to think that it was possible before 2.5

cheers, kami

[JDHill]

No, you cannot have different UVs on different instances of a given block definition in Rhino -- by definition, each block insert is an instance of the block it instances, so when you change the definition, you change any instances of that definition. The second issue of real scale vs. blocks is related to this; the primary function of real scale is alter the UV mappings of any objects the texture in question is assigned to. That is all well and good for normal geometry -- when you change texture scale, the plugin loops through all the objects in the document, finds out if they use this texture, and alters their UVs if they do. The same does not currently apply to block definitions, but let me look into it and see if I can do that.