FryRender (New Kid on the Block!)

Richard

what I didn't like about maxwell (don't know if it changed by now) is that you do not have a representation of an imported maxwell material in SketchUp; meaning that if you apply a material to a model, then link a maxwell material to it, you do not see this linked texture on the SketchUp model. in order to get the UVs right, you have to import the diffuse map to the material manually.
if I import an indigo material however, the dif map is applied to the model automatically.

hmmm? not quite sure I understand that exactly! I know from my experiences with Indigo they seem to work very much the same excepting that I must have all materials used in the indigo material in the SU browser! As opposed to the Maxwell method of only one map needing to be imported. This can weight models fairly heavily.

I'm not sure at all how you are getting a material to apply to your model without painting it on to the required surfaces and then setting the UV's manually?

plot-paris

I am afraid, I didn't explain it well enough.

what I meant is, if you paint a cube with a red colour for example. now you assign a material to this colour, lets say a brick texture.

if I load a material in indigo, the coloured faces will automatically change from mere red to the brick texture of the assigned material.

however, if I link a material with maxwell, the painted faces keep the simple red colour. in order to manipulate the uv-set, I manually have to import the diffuse map into SketchUp.
I would like to see maxwell overwrite the original material (red colour) with the assigned one (brick material).

but I perfectly understand what you mean with

@richard said:

I must have all materials used in the indigo material in the SU browser!

the necessity of having every bump- and clip-map in the material browser, can be really annoying, especially when you absentmindedly purge unused materials (which deletes them, because they are not actually assigned to any material).

lewiswadsworth

Linux!

Richard

@plot-paris said:

especially when you absentmindedly purge unused materials (which deletes them, because they are not actually assigned to any material)

I bet you only did that once!!!!!

Ok I understand what you mean there!!! I must say I'm personally glad of the current workflow of the material not being replaced as I rarely use the diffuse map from the maxwell material. I have a low res image of most maxwell materials that I place in SU to ensure better performance and stop SU bogging with heavy textures!

I must say the all maps in scene issue of indigo was what I've found to be my biggest bug bear with it. For most brickworks for example I use 3 diffuse maps and one bump map and for many other materials I use more than one diffuse so my material browser in SU goes WOE!!!!

BTW Luxrender lux good!!!!

693!!!!

kwistenbiebel

Oh yeah....The 'purge unused' function is off limit when using Indigo

plot-paris

@richard said:

I have a low res image of most maxwell materials that I place in SU to ensure better performance and stop SU bogging with heavy textures!

oh, I thought SketchUp reduces the image automatically to 1024 px. does it in fact keep the whole texture and only displays it with 1024? that is truely nasty!

the great thing about Indigo is "Whaat" - I mean, he is an active member of this forum and so all our wishes and ideas definitely find their way to the right person.

jenujacob

@kwistenbiebel said:

Oh yeah....The 'purge unused' function is off limit when using Indigo

i usually paint the bump/clip map etc on to the reverse side of the face.. thereby i can easily purge unused items off my model!

Richard

@jenujacob said:

@kwistenbiebel said:

Oh yeah....The 'purge unused' function is off limit when using Indigo

i usually paint the bump/clip map etc on to the reverse side of the face.. thereby i can easily purge unused items off my model!

Now that is clever!!!!!!

It could actually be an idea for Indigo users to set up a grid tiled plane using the sandbox from grid option, then all used materials could be painted to it and then placed on a hidden layer for export.

I know when I first started using Maxwell in the beta days materials needed to be created internal to SU then I used a similar method to what I'm suggesting to make a tile of material an saved it as a component or group. I could then drag this into scene and model up off it to maintain the material properties to all new geometry. It worked well.

Plot:

Mate I'm not quite sure about how SU reduces materials though I know if I bring in a 2Mb texture the SU file seems to grow about the same size! I actually push the low res images used for painting in my model way way down in size and it really helps to reduce the hang caused by the material browser when painting.

BTW I totally agree with you in regards to Whaat's development of the Indigo plugin! At the same I have much similar admiration for Pavol's development of the Maxwell plugin. Both have achieved amazing work, although Pavol isn't around these forums he is ever present on the Maxwell>SU forum and listens well to user feedback. That said and in great respect of Whaat - he manages to generally answer users needs well before users can even think of them!!!

boofredlay

697

plot-paris

so the perfect solution for a SU plugin of a render engine (no matter which) would be to:

store the material information externally
automatically import a lo-res image (perhaps even baked) of the material to SketchUp, when loaded
direct control of material attributes within SketchUp - changes affect the externally saved material-file.
[Edit]or information of changes are saved in the SU file (attatched to the SU-material, but can be applied to the external material-file, if needed. thus you can have a library of mats that will never be changed, but you can still do indivitual changes within every model...

I think that is pretty much the positive aspects of the different approaches combined. and it would mean the easiest workflow ever for rendering!

Stinkie

@richard said:

@unknownuser said:

Too bad, really, that neither Fry of Maxwell has SkIndigo's intuitive approach to material editing. That's where both apps, imho, really fall short in accomodating SU users.

Hmmmm? I would strongly suggest the opposite - the blended material setup with Indigo for me follows nothing toward a intuitive approach. When Maxwell was in beta it relied upon all material setup being done directly in SU and the best decision they made IMHO was to introduce a standalone material editor!

I've never used a blended mat. I was referring to -technical term!- "normal mats". Don't get me wrong here, I like Maxwell, but really, when it comes to setting up, say, a nice parquet mat, (Sk)Indigo wins hands down with regards to speed and user-friendliness.

I say all of them software boys start working together.

Whaat

@richard said:

I must say the all maps in scene issue of indigo was what I've found to be my biggest bug bear with it. For most brickworks for example I use 3 diffuse maps and one bump map and for many other materials I use more than one diffuse so my material browser in SU goes WOE!!!!

So...if I were to 'fix' this than I could convert you to Indigo once and for all???

If I understand you correctly, you have to manually create a low-rez version of your texture in order to do the UV mapping in SketchUp. Then, you just 'link' to the MXM material using the plugin, right? Or is there another step?

Richard

@plot-paris said:

so the perfect solution for a SU plugin of a render engine (no matter which) would be to:

store the material information externally

automatically import a lo-res image (perhaps even baked) of the material to SketchUp, when loaded

direct control of material attributes within SketchUp - changes affect the externally saved material-file.
[Edit]or information of changes are saved in the SU file (attatched to the SU-material, but can be applied to the external material-file, if needed. thus you can have a library of mats that will never be changed, but you can still do indivitual changes within every model...

I think that is pretty much the positive aspects of the different approaches combined. and it would mean the easiest workflow ever for rendering!

Mate!!!!!!!

I think you just hit the perfect SU user prefered workflow on the head!!!!

I certainly one who likes the ability to save and access commonly used materials for later use and certainly not use large scale maps in the model. and certainly like the external referencing of materials, I will often have more than one material using the same map in SU - for example I may have a few types of brickwork for which I position the bump map and add colour (say bright green) in SU and link it to the maxwell material of choice - then make another material
with the same map and again colour it (say bright blue) in SU and again liknk this to another maxwell brick material of choice. This allows me to quickly test various material options just by relinking the SU map to another material.

All that said - one of my loves of Indigo is the option to colour edit maps in SU and they are exported to render holding the SU colour editing. I know this sounds like I want the best of both worlds!!!! Yep!!!!

I think that is where both systems break down - options for workflow!!!!!

I think the ideal workflow would be the option to externally link materials and those not linked holding any colour editing from SU. However it would be great if SU did possess better image editing options.

One of the key upgrades recently to the current version of Maxwell's material editor is the ability to adjust the saturation, contrast and brightness of maps. This allows a single map to be better used in the reflection, specularity and bump channels. One map for all and all handled by the editor!

Richard

@whaat said:

@richard said:

I must say the all maps in scene issue of indigo was what I've found to be my biggest bug bear with it. For most brickworks for example I use 3 diffuse maps and one bump map and for many other materials I use more than one diffuse so my material browser in SU goes WOE!!!!

So...if I were to 'fix' this than I could convert you to Indigo once and for all???

If I understand you correctly, you have to manually create a low-rez version of your texture in order to do the UV mapping in SketchUp. Then, you just 'link' to the MXM material using the plugin, right? Or is there another step?

Whaat - yes mate that is the workflow regarding the use of lowres images. I open the large map in PS and using the "save for Web" function save the image out at the same pixel dimension but at lower image quality. This allows the UV's and scale to be set correctly.

In regards to adoption of Indigo to workflow. I must say so many functions of Indigo are second to nothing else out there (HDRI positioning for example)! I think the blended materials for me personally isn't working currently I believe due to this aiming to all be achieved inside SU - I just can't see this will ever work! Some may have a handle on it but it's still a lot of work! Though for examples like your tut with the graffiti wall it has some very destinct advantages! ie where non commonly sized maps can be accurately located!!!!!

Mate I did suggest the multiple maps having to be in model is an issue the other big one for me is Indigo's pace at initial clean up of the rendering - this means although the final render is of great quality one has to wait initially a considerable time for the render to clean sufficiently to confirm materials etc are on target. I would suggest within 5-10minutes maxwell gives enough clean up to assess the materials, Indigo seems for me to be over an hour for the same scene although final clean up times can be similar!!! This can mean unless the material outcome is well understood quick material testing by export is somewhat hindered.

BTW I have very little doubt that Indigo will become the industry leader as time progresses given as Plot suggests your listening and implementing!!!

Cheers mate! Richard

Whaat

@richard said:

Whaat - yes mate that is the workflow regarding the use of lowres images. I open the large map in PS and using the "save for Web" function save the image out at the same pixel dimension but at lower image quality. This allows the UV's and scale to be set correctly.

Well..this feature has already been implemented in the latest SkIndigo beta (1.1.5). All that's missing is a tutorial on how to effectively use it.

@unknownuser said:

Mate I did suggest the multiple maps having to be in model is an issue the other big one for me is Indigo's pace at initial clean up of the rendering - this means although the final render is of great quality one has to wait initially a considerable time for the render to clean sufficiently to confirm materials etc are on target.

It has been requested many times for Onosendai to implement a small 'render preview' window similar to Fryrender and Maxwell. I have little doubt that he will eventually add this. In the meantime, there are many ways to confirm materials that are quite fast. For example:

Use the material preview scenes - the sphere scene is clean in only a few seconds - you can also render multiple previews using different settings at the same time (how's that for efficiency? )
Region rendering (select a small window of the scene and render that portion only)
Selection rendering (render only the objects that you have selected)
Render lower resolution
Try a different render method - For example, outdoor scenes with lots of direct light will be clean VERY fast if you use simple Path Tracing (as opposed to MLT). I have a feeling that Maxwell uses path tracing which might exlain why the image is initially fairly clean but then takes quite long for 'final convergence'.

Thanks for the compliments and the crits, mate!

kwistenbiebel

I must say that Skindigos material setup is the most easy and fastest around.

For more complex materials with multiple uv-sets per map, it is somewhat less intuitive.
For instance, having a pure color as diffuse map and at the same time a positioned bump map in a material asks for some additional steps .

But otherwise, Skindigo rules as it comes to swift material setup.
Most of the time, I see myself clicking a preset and finetuning it just a bit and done.
Setting up a material is really a matter of seconds after a while.

The FryRender material editor is somewhat more elaborated, very functional (you can edit the bitmaps), but on the other hand I really miss more preset materials to start from.
There are some, but when clicking them (e.g a shiny plastic), the preset material overrules the assigned bitmaps. So actually, the presets give you more work as you need to re-assign the native bitmaps.

Richard

@whaat said:

Well..this feature has already been implemented in the latest SkIndigo beta (1.1.5). All that's missing is a tutorial on how to effectively use it.

I should add and not sure this is the full functionality of the new changes in 1.1.5? As you suggested earlier I only use the low res map for placement then link to the Maxwell material with the full res map!!!!!!

@unknownuser said:

It has been requested many times for Onosendai to implement a small 'render preview' window similar to Fryrender and Maxwell. I have little doubt that he will eventually add this. In the meantime, there are many ways to confirm materials that are quite fast. For example:

Use the material preview scenes - the sphere scene is clean in only a few seconds - you can also render multiple previews using different settings at the same time (how's that for efficiency? )

Region rendering (select a small window of the scene and render that portion only)

Selection rendering (render only the objects that you have selected)

Render lower resolution

Try a different render method - For example, outdoor scenes with lots of direct light will be clean VERY fast if you use simple Path Tracing (as opposed to MLT). I have a feeling that Maxwell uses path tracing which might exlain why the image is initially fairly clean but then takes quite long for 'final convergence'.

Mate I'm not so much suggesting the small preview window as used by maxwell - which is really only of use for lighting settings but the full size render! Yes Maxwell could use some magic to clean the render early certainly - can't confirm that at all!

I will try and test some of your other suggestions!!!! I can see value of the low res or path trace methods, I normally export to maxwell one or two test renders from SU so I can see all materials in scene and then make any required adjustments to all materials prior to final export. With lights off for exteriors these clean quickly and cleanly enough early to see what changes are needed. If the path trace method provides this work around that is a great alternative!!!!!

@unknownuser said:

Thanks for the compliments and the crits, mate!

Are any thrown your way capable of covering the work you have done in furthering the application of SU - not nearly!!!!

plot-paris

let me just express how much I value the material preview render of indigo, Whaat. that is such a great tool and helps me a great deal, especially in getting reflections and roughness right.

(I think this thread has been jacked some posts ago, hasn't it? )

Richard

@plot-paris said:

I think this thread has been jacked some posts ago, hasn't it?

Hmmmm? Think your right there! Well at least it's useful discussion!!!

FRYRENDER (new kid)!

Just thought I'd mention it again! Are we back on track?

dsarchs

[rant]

The problem with looking at new rendering engines [and I have to admit, I've been pretty impressed by Fry render, so far] is that the examples are almost always these amazing scenes, full of modeled detail.
Pretty much any rendering engine could produce amazing results based on the models. In these cases its the large amount of detail, and not the rendering quality that's on display.

The best way to judge the merits of various rendering engines is to do a side-by-side comparison of the exact same scene rendered by different engines for a set length of time. This can become complicated somewhat by time differences between biased and un-biased methods [maxwell or vray, for example].

Beyond this, its the features each engine supports [displacement, instancing] and the ease with which that engine can be used and learned.

[/rant]