[soarchitect]

issue
There is a material scale problem if the real-scale (meters) option is used for mxm materials. The problem occurs when exporting to MR or Studio via
a plugin when real-scale texture maps are used in the host program. Basically, the material scales either too big or too small.

workflow
real-scale is an important option for me because my materials are primarily architectural materials, scale needs to be controlled. Most of my mxm materials are created this way.
Ideally, once I establish the correct scale in meters for a texture map, I should be able to apply the material any object.

What I found is that real-scale (meters) works great if you do all your texturing inside of studio. However, if you use textures at real-scale inside another program, such as sketchup or
microstation, the exporter will enlarge the mxm material by a factor equal to the numeric value inside the mxm.

The workaround as I understand it, is to use 'relative scale' mxm materials, this will allows the plugin to export correctly. Unfortunately, if I want to do additional texturing inside of Studio,
relative scale will not work because it is not ideal for architectural materials.

challenge
It seems that there are two methods of controlling material scale which don't work well together. This is a huge problem as it compromises the ability to maintain a consistent material library.
I don't have much interest in maintaining both a real-scale and relative scale variant of the same material.

I am not sure what Next Limit has in the pipeline, but here are a couple of suggestions:

1) Ideally, Studio would automatically recognize the conflict when importing from a plugin and make the adjustments on the fly. It seems to be a relatively simple problem to resolve since mxm uses the same textures whether relative or real scale is used.

2) The mxed could have a 'global scale' option to adjust the scale of all maps with one toggle, versus adjusting each map independently.

3) The mxed could have an option to export a 'real-scale' or 'relative-scale' version of the material.

solution
Any word from Next Limit on future development would be greatly appreciated.

[stonelli]

Sean, this is complicated.

As far as I can tell (never got a totally unanbiguous reply to my queries on the developer side of the Forum, and I am not a programmer) the plugin SDK currently forces the exporters to create locked (relative) projectors, so when you export to Studio using a patterned material and create projectors, then link the MS material (and you seem to indicate that the same happens with Sketchup, maybe in a different way) to an MXM that has Metric tiling enabled that tiling just becomes a multiplier, as far as the Relative projector is concerned.

I have a trouble report open in the developers forum about the fact that Studio has import preferences to create a projector per object, at import, which it is doing, and to normalise where needed, which it is not currently doing, or not for the Metric MXMs it is finding in the MXSs that the MS exporter is creating.
There are other priorities now but I hope this can be given some attention, at some point.

If you look on the developers side, you will see that I have also asked for the SDK to allow the plugins, that can, to create Cubic Normalized projectors when they know that they are sending out a Metric material. Problem with that is that, while in other programs like MAX a normalized, or real world, projector is just a cube at 1x1x1 of size, NL has taken a different approach. The projector, by default is a cubic at the world extents of the object and normalization scales it by the amount necessary to make it a 1x1x1 cube. The problem with this is that, on the export side it would not be as simple as allowing the creation of a 1x1x1 projector. The exporter would also need to be able to actually reed the Metric MXMs tiling data in order to be able to, instead, apply ther required normalizing rescaling.

Keeping in mind that my understanding is probably simplistic, I hope that someone at NL can clarify if I am way off

I have argued that this whole projector thing needs a thorough relook, with a mind to create a true Metric projector, not just a normalization mechanism but don't know where this stands on NL's priority list.

Never quite understood why so few are interested in the idea of a material that you set up once, properly, and then reuse at will witout projector worries (except for when Cubic is not the right projection type
Maybe it is because, coming from MS, we have always had real world scaling.

Ciao

[soarchitect]

Never quite understood why so few are interested in the idea of a material that you set up once, properly, and then reuse at will witout projector worries

I was thinking the same thing, then I realized that most people using Maxwell are not rendering objects greater than 1mx1mx1m. It almost does not matter if real scale is used or not,
the difference in the size of the texture map from export to studio is probably negligible.

I am getting an uneasy feeling that this program is not suitable for architecture. Relative scale is not an option, it puts a major kink in the process. Scale needs to be maintained throughout the workflow.

This is a simple diagram of the problem (from host app to Studio)
metric scale > metric scale = textures are distorted (scaled up or down)
metric scale > relative scale = textures accurately reflect host app. Good luck trying to apply a relative scale material to a real scale object inside of Studio.

As it stands, these seem to be my best options:

option A
Don't texture anything in 3d app, export geometry into Studio and texture with real scale mxm's.
pro: materials are consistent scale (metric scale)
con: UV tools not used in host app. Not able to see textures in host app.

option B
Texture map everything in 3d app, export directly to MR (by passing Studio)
pro: material scale can be controlled in host app.
con: Studio is no longer usable as materials must be relative scale. lose Studio functionality, including Fire

To be honest, I don't have enough experience to know which is the best option. getting frustrated.

[Half Life]

In Sketchup you have a 3rd option which it to set materials via Maxwell plugin and use the Maxwell plugin UV override context menu to apply "realscale" UV's.

The only downside of this workflow is you will not see a preview of the material on the model(within the host app), however this is a limitation of Sketchup which is not friendly towards external UV mapping/texturing (along with no support for bump, displacement, and normal maps internally).

I see there being a very distinct line between modelling app and rendering app in this scenario and often prefer to use Studio... although this is gradually being changed as the improvements for the plugin and addition of things like FIRE make those limitations moot.

Best,
Jason.

[soarchitect]

Jason, thanks for the info. It would be very hard for me to work without seeing accurate textures, unless I make all my building out of glass.

I see there being a very distinct line between modelling app and rendering app in this scenario and often prefer to use Studio

'inside baseball': If your preference is to use Studio and real-scale mxm's for texturing, are any materials/colors applied in Sketchup?

although this is gradually being changed as the improvements for the plugin and addition of things like FIRE make those limitations moot.

I guess you are suggesting Studio will not be required in the near future? The problem is if you use the plugin only, you will have to reconfigure all the materials in your library to relative scale.
If you were just beginning in Maxwell today, would you stil use real-scale mxm's?

Best,
Sean

[brodie_geers]

Real scale might make sense in some modeling apps but I don't understand why you'd use it in conjunction with SU. JD (NL employee who creates the SU plugin) has stated before that he would be perfectly happy with removing it altogether from the system.

I've wrestled with real-world on occasion because it sounds good in theory, but SU is inherently real-world scale. So if you've got a texture that represents 3mx3m you can easily input that info into SU and SU will display your texture at the correct size and Maxwell will render it at the exact same scale if you use Relative.

But to use Real-World, you'd have to tell sketchup that it's a 1mx1m texture (and it would look wrong in SU as a result) and then tell Maxwell that it's 3mx3m to get it to export correctly. Where's the advantage? In fact there are disadvantages here as it's more confusing (as you're seeing) and it's less flexible.

I CAN see how it would be helpful when texturing within Maxwell because maxwell isn't inherently real-world scale with relation to UV's. To that I would say, why are you texturing in Maxwell? Again, where's the advantage? If part of your building changes it you'll need to alter it in SU, change out that piece in studio, and retexture it again. Sounds unnecessary.

My workflow is to texture everything in SU. I have a list of standard materials (concrete, stucco, sidewalk, asphalt, etc.) which I've added to my SU material library as I've went so the texture sizes are saved within the material (so the material size is set once and I never think about it again unless I decide to manually change it for some reason which I'm free to do). My materials are all set to relative so my UV's are maintained when I go to Maxwell.

The idea that Maxwell isn't suitable for ArchViz because of issues with Real-World scale is false. There's no reason that Relative should be any less accurate - it's just that you're telling SU that the texture is 3mx3m rather than Maxwell.

-Brodie

[soarchitect]

Brodie,

I agree with a lot of what you are saying, clearly you have gone through this issue and have made adjustments to your workflow.
I am guessing, but It sounds like you don't use or need Studio that much?

I use both SU and Microstation. Microstation also uses real scale logic. However, that plugin has not yet reached the maturity of the SU plugin, It does not have for example 'fire' implemented.
Chris (the developer) has done some amazing work with the plugin, it is the reason I purchased a Maxwell license to begin with.

I may have to re-think my strategy, but I conceptually thought of Studio as more the 'hub' in the workflow. All apps excel at some things, and fail at others. As such, it may take
a couple of different apps to create one scene, which would then be composited inside of Studio. Because more than one app is used, a universal method of handling mxm's is essential.
Relative scale may be the answer. If so, the role of Studio would primarily be used for lighting and camera setup. Which I am ok with, as long as I know that from the beginning.

As my firm grows, and Maxwell can effectively be managed in multi-team/multi-app environment, then I would be more than happy to invest in additional licenses.
What I can't understand is, why offer the ability to create real or relative scaled materials, and then poorly integrate that option into your software. It does not make sense.

Thanks for sharing your thoughts and workflow. Greatly appreciated.

Sean

[brodie_geers]

I do use Studio on a regular basis actually (I think this is much more common for SU users than, say, 3ds Max users). And I do agree that you should use each program for what it's good at. That being said, Studio doesn't really excel at very much. NL, puts a lot more time into the rendering engine than the Studio (rightly so).

In my mind Studio excels at camera placement, managing high poly scenes and stability. I haven't found a scene that's too big for Studio and I don't think it's ever crashed on me which is amazing (although I have had some viewport issues). It's not very good at editing, texturing, placing objects accurately, etc.

I have used studio to place high poly objects like trees and cars which are impossible to place in SU. I often adjust or place my camera using studio and I find FIRE seems a bit snappier in Studio which helps with this. Likewise it's a nice tool for adjusting lighting for the same reason.

As a general rule though, my advice is to use Studio as little as possible. Even when I make tweaks to the Environment or material setting in Studio, for example, I'll go back and adjust the Env/material settings in SU accordingly. That way, if/when I have changes down the road I can just make the changes in my SU file and reexport. The most I'll need to get from my old Studio file is the Camera assuming I'd placed it in Studio (for this reason I'm placing it more in SU these days which is no big deal since JD was able to translate SU's 2-point perspective camera into Maxwell).

You're on the right track with using Studio as a hub though. I've done that as well when I have assets coming from SU, Rhino, and 3ds Max. It's a good stable collecting area.

In my opinion Real World scale isn't poorly implemented in Maxwell, it's just that it's a sort of non-intuitive workaround of sorts. I don't quite understand the issue you were having with it but it sounds like a misunderstanding of how it works. For example, in SU if you've got a concrete texture that represents 5mx5m of concrete you'd place your map into SU and set it to 1mx1m. At export, Maxwell will increase the size by 5x. Likewise if it was a rock sample of .2mx.2m you'd set it to be 1mx1m in SU and at export it would decrease the size by 1/5th. So it works...it's just that it doesn't make sense. You end up with really huge rocks in the SU viewport and a concrete texture which tiles 5 times more than it should. That's not terrible for concrete or rocks but what if you're trying to accurately place bricks or some other material?

-Brodie

[soarchitect]

Brodie, your observations are spot-on. However, I do understand how to use real-scale mxm's, but as you point out, they are not intuitive. It is not a wysiwyg workflow.
I believe you are also correct in identifying the weaknesses/strengths of Studio. This is the way I am going to approach it moving forward.

The only negative at this point is the realization that i am going to spend a few hours converting a few hundred materials from meters to relative.
Better now than later.

Best,
Sean

[brodie_geers]

Yeah, that is quite a bummer. I suppose if you were a script guru you might be able to write a script that did that for you which would be wonderful. There's a script floating around (found it http://www.maxwellrender.com/forum/view ... er#p334361 ) that will open all of your mxm's and save out a new preview scene so I'd think what you'd want to do is possible. But I don't know the first thing about that stuff. Perhaps if you know a techy who would trade services for beer you might save yourself some time.

-Brodie

[Half Life]

I feel your pain -- I have a library I update for each new version that has well over 3000 materials in it many of which are set up to use "realscale".

Studio is less necessary if you are only using one application to model and it has a capable Maxwell plugin (like Sketchup) -- this is primarily due to the inclusion of fire which allows you to see things the Sketchup "viewport" would never allow (in "real-time").

That said, things become much more complicated when you are using many apps, and especially so when some of those apps do not work well with each other or with Maxwell (ie no plugin) -- in those cases Studio provides an excellent unified workspace to gather all the disparate elements into and work with.

Best,
Jason.

[JDHill]

Just some comments on this....

First of all, let's start by stating two pivotal facts:

1. Real Scale is only an on/off switch in a texture, which conveys a particular intention.
2. When it is enabled, the engine uses the reciprocal of the texture's specified tile values.

The first is fairly obvious, since there are no objects in the picture when we are in MXED editing a texture's parameters. The second is not so obvious, and bears some discussion. Normally, by 'tile' we are saying to the engine: squeeze this many copies of the texture into the given space. What space is that, though? With relative textures, it doesn't matter; we are just going to put x-number of copies into it, whatever it happens to be. With Real Scale, though, that goes out the window: it is precisely the size of this space with which we are concerned.

And under Real Scale, this space is assumed to be 1m x 1m, hence point two above. But how do we get this 1m x 1m space? Flipping a switch in a texture does not magically bring it into existence. And what happens if the space is not created at that size? You're not going to get meter-sized textures. Let's say, though, that a plugin is going to create this space for you: a simple on/off switch tells it nothing about where the textures should be positioned, and how they should be oriented.

Real Scale, then, represents a promise which is made, but not kept, by a texture. for Studio, it's entirely possible to fulfill what it promises, since Studio completely controls how UVs are defined and managed. For a plugin, though, it is not a question which can be answered universally; it depends upon how the host application works. Take, for example, SketchUp. SketchUp does not possess any concept of tiling textures within UV space; you type in 2m and you get 2m, and that's it (if you 'position' the texture, you modify UVs for the face).

Let's walk through it. Say that you put a 2m x 2m Real Scale MXM on a 2m cube in SketchUp. After pushing its active texture into the SketchUp material, you set the texture's size to 2m x 2m in SketchUp. SketchUp creates UVs which render the texture at that size, and as expected, you see it repeated precisely once on each cube face. But it doesn't render that way in Maxwell. Why? Remember, this was a 2m x 2m Real Scale MXM. Why should that be a problem? Because as I wrote above, the render engine assumes a 1m UV space, and we have created a 2m space in SketchUp, so when we render, we will find that we only see 1/4 of our texture: it has been tiled relative to UV space using a factor of 0.5, or 1.0 / 2.0. If our texture were 1m x 1m in SketchUp, this would be perfect, because in the context of that 1m space, a tile value of 0.5 results in an effective tile size of 2m, just as we had specified in the MXM texture tile values.

How can we remedy this? Well, if you reason it out, you will see that we can't. To see something at 2m in SketchUp, the texture has to be sized at 2m in SketchUp. But when we do that, we are not following the convention that Maxwell needs us to follow in order for it to hold up its end of the Real Scale contract. The conflict is literally unresolvable, due to the two systems having fundamentally different conceptions regarding the way that textures are supposed to work (keep in mind too, I'm only writing about SketchUp here -- other hosts have their own peculiar sets of conceptual conflicts).

At this point, we might notice that the issue could be at least partially solved by simply having Maxwell treat all textures as having 1.0/1.0 tile values when Real Scale is enabled. That would fix the problem here -- our 2m UV space from SketchUp would be seen as 2m in Maxwell. Notice, though, that this would effectively mean turning Real Scale into a non-feature: when you enabled it, Maxwell responded by not doing anything at all -- with the very important exception that the value of the Real Scale switch would still be riding around in MXM files, delivering your intent throughout the system.

I personally think that would be highly preferable, because as things currently are, Real Scale is writing a check that some plugins and host applications simply cannot cash. The result is general confusion and frustration. While the only real solution to that problem is removing it from the MXM spec, and instead, allowing plugins to provide it where they are able to do so, I do see the value, as I wrote above, in allowing the intention to be communicated via MXM. So, I don't yet see any perfect solution: it is a case of choosing between minimizing confusion and maximizing utility.

[soarchitect]

JD,

Thanks for bringing some clarity to this issue, I can understand why this is a difficult problem to resolve, if at all possible.

At this point, we might notice that the issue could be at least partially solved by simply having Maxwell treat all textures as having 1.0/1.0 tile values when Real Scale is enabled. That would fix the problem here -- our 2m UV space from SketchUp would be seen as 2m in Maxwell. Notice, though, that this would effectively mean turning Real Scale into a non-feature: when you enabled it, Maxwell responded by not doing anything at all -- with the very important exception that the value of the Real Scale switch would still be riding around in MXM files, delivering your intent throughout the system.

If as you say, this problem can be partially solved by having Maxwell treat all textures as having a 1x1 scale factor upon import, in this scenario, would the mxm revert back to a 2x2 UV if applied to new objects inside of Studio?
(ie, ignoring real-scale at import, utilizing real-scale inside studio). Or by 'non-feature', do you mean the mxm essentially behaves as relative-scale material inside Studio as well?

Thinking about this further, I see a value for real-scale mxm's for users that have 3d applications where a maxwell plugin does not exist (geometry would be imported through a format such as obj). Because these users would
depend on Studio, real-scale is almost a requirement to be able to texture objects with accuracy.

I will say however, whether a plugin is used or not, it would be nice to have the flexibility of using Studio to its full potential.

Best,
Sean

[JDHill]

If as you say, this problem can be partially solved by having Maxwell treat all textures as having a 1x1 scale factor upon import, in this scenario, would the mxm revert back to a 2x2 UV if applied to new objects inside of Studio?

To be clear, it is Maxwell Render, not Studio, which would treat RS textures as having 1 x 1 tiling values, and it would do so at render time.

(ie, ignoring real-scale at import, utilizing real-scale inside studio). Or by 'non-feature', do you mean the mxm essentially behaves as relative-scale material inside Studio as well?

Regarding Studio, the difference in its behavior would be that where, given a 2m x 2m RS texture, it currently generates UVs based on a 1m cube, relying on the engine to render using a 0.5 x 0.5 relative tile size, it would then generate them based on a 2m cube. When you changed the tile size, new UVs would need to be generated.

Which is to say that all the work would fall on Studio and plugins, rather than splitting the task between them and the render engine. Note that this would preclude the system from retaining a particularly appealing facet of its current implementation: since RS UVs are currently expected to be generated at the 1m size, two RS textures which use different tiling values can share one set of UVs and still achieve different real tile sizes. If the engine were no longer going to do tile sizing for RS textures, this would no longer be the case, and textures with different RS tiling values would each require their own channel, and their own set of UVs.

[stonelli]

Guys, my Gmail had decided that the notifications were spam so I did not get any for a while, thus the late re-entry into this thread.

Shame, as it would have been nice to participate all along.

As I see it, part of the issue is that each host program has it's own different way of dealing with mapping so, for some, Real World is not a real option, but for the ones that already think that way, it would be nice if NL made it easier to implement a RW workflow.
This is the point at which I am still confused. Speaking for MS, I know that it clearly thinks in Real World and that, given the chance, it should be able to create RW MXMs and 1m (normalized) projectors for each object it exports. What I am unsure about is whether the SDK allows it, as I never got a definitive answer to my queries about this.

On the developer side, I have an open TR for the fact that Studio is not currently creating and automatically normalizing projectors where required, at File/Open.
If you make a material become RW when already assigned, then Studio does offer to normalize all affected projectors.
My test had been to use a feature in the MS exporter that reuses existing MXMs if it finds them in a specified folder, and I had pre-populated the folder with a RW MXM, before exporting and asking MS not to create a projector (MS exporter gives you the option to Not Create, Create only for objects that have a MS patterned material assigned to them, or Create for All objects, in which case, at this point, it creates a relative projector at the full extents of the object, like Studio would) but Studio created the projector, as instructed in the preferences, but failed to normalize.
My suspicion is that it is not checking the MXMs that are rolled into the MXS to see if any are RW and act accordingly.

Right now, MS is creating "locked" projectors which, once unlocked, become very hard to deal with in Studio because it, rather than stating the projector's size, lists it's scale relative to the object instead so that for the user to get it back to the magic 1m cubed size, requires knowing the extent dimensions of the object. This is not helped by the fact that even in the Object Parameters that size is not listed, which means that you have to go back to the host for that information.

If, as JD says, one solution would be to get rid of the RW concept and simply allow the host to decide whether to define the repeat in the material or the projector, which is essentially what we are talking about, then I think we should discuss it further.

Certainly the current status is unsatisfactory for the ones of us that still need to use Studio.

For the sake of fairness, I should point out that, right now, if you use a patterned material in MS and let the exporter create the relative projector for it, the results are correct in the vast majority of cases, the exception being the few situations where MS itself is confused about how to pattern the given object.
The issue is with the way that NL chooses to show the projector info. Even just showing the size, rather than scale, would be a big help for when you need to do projector edits in Studio.

The reason why I have been after the RW solution is that, for me, if I am going to render in Studio I really don't want the requirement to have a parallel set of MS materials. I would just rather be able to assign my MXMs directly, something that can't be done until we have a solution for RW :-}

Have not checked the current beta's status relative to my MS export test that lets Studio handle the projections, will do and post in that thread.

EDIT, can confirm it still does not work, Studio will create a cubic projector but not normalize it, my guess is that, at File/Open, it is not checking the materials to see if any are metric.

Ciao