Texture Scale

[Cary OConnor]

Hi All,

 

I have a general question. By default, IRONCAD is set to "Fit" textures to parts when dropped from the catalog. You can see this is you create two blocks at different sizes in the scene and drop a texture on them (they will be different in size).

 

Under Tools/Options/Parts, there is a setting to change this to Scale to a particular value say 100%.

 

My question is should the scale be the default?

 

I don't see why it would be necessary to fit the texture in the same scene. In general you could be using the same texture and parts would appear different depending on there size. Is that really what you would want? To me, I think I would want a consistent looking texture in the scene when I drop. I get that behavior if I use the eyedropper.

 

Please let me know if you agree.

 

Why I ask is if we want to add an option to sort of link smartpaints, the size of the texture is an issue. For example: Say you have 10 parts using a texture. You now want to change a smartpaint setting and apply to all shapes that have the same smartpaint settings. If we compare the smartpaint settings, the texture size can cause an issue. So we can:

 

1. Ignore the texture size - The issue with this is that the smartpaint may change on parts that you do not want to change.

 

2. Look at the texture size - Issue with this is that right now it is easy to make the sizes different and then the apply to all really will not work well.

 

In my opinion, I think we should be looking at the texture size. Do you agree?

 

Cary

[Guest EricFoy]

Cary, here's my thoughts:

 

A texture or bump map is placed onto a part in order to model a real texture that has a real scale, regardless of the size of the object being painted. Therefore, it makes the most sense to have all scaling parameters relate to the global coordinate system, rather than to the dimensions of the part or surface. There are, of course some exceptions, but I believe they are rare.

 

So the DPI attribute of eg., a JPEG file immediately comes to mind. The problem with DPI is that it relates to the final printed size of the image, not to any dimensional attributes of objects depicted in the image itself.

 

So what about having IronCAD maintain a registry of texture images into which the user would simply enter the image along with its actual physical dimensions. It could work like this:

 

Upon painting a part with an image, IC would check to see if that image is in the registry. If it isn't, IC would ask the user for either an X or Y dimension of the image. If X is specified, then Y would be computed from the aspect ratio of the image, and vice-versa. OPTION: Alternatively, the user could specify both X and Y, in which case the image would be squeezed to fit. These values would be written into the image registry, as well as being written as data into the scene file. This proposed dialog illustrates how it might work...

So when a file is opened that contains an image not in the local machine's image registry, IC would get the scale data from the file and register it automatically.

 

The possibility of name collision comes up, so perhaps IC could store a checksum with the name in order to warn the user in case of name collision.

 

Anyway, I think that this would make it possible to drop a texture onto a part with a minimum of doubt as to the expected results at render time. In short, I would like the drag and drop behavior to simply default to the registered scaling. This would be much superior to the current "fit" behavior.

 

Now global editing of textures could be accomplished by editing the registry directly. Any textures that are either locked to the registered scale, or to a scale factor thereof (see the dialog above) would automatically change scale when the registry is changed. The "Explicitly scaled" textures would remain as they are.

 

Sound good?

Edited May 16, 2010 by EricFoy

[dhovatter]

Cary

I did like you said and put two cubes in the scene, much different in size, and added the bumpy texture.

It is dramatic the difference you get.

I agree that if I were making two different size parts in a scene and wanted a texture on them I would want the texture to be the same scale regardless of the part size. it is like typing a document you only want the character size to change when you want it too. A document would look dumb if the characters just changed size at there own whim.

Dallas

 

[Cary OConnor]

Eric,

 

Why is the scale of the image not valid compared to your XY concept?

 

Cary

[Guest EricFoy]

Sorry Cary, but I don't understand the question... Could you elucidate?

[IronKevin]

Hallucinate?

[Cary OConnor]

Each image has a size when inserted into the system. When I meant scale, it means a scale applied to that size. So for example: You have an image that is 10x10px. If we use scale, the image would always be a consistent 10x10 and no fitting will apply unless the user wants to set it to Fit (as is the default today). It makes it simple to understand in that regard.

 

Cary

[Guest EricFoy]

I think we need to define some terms here. Here's what I'm thinking. Please correct me if I've got it wrong:

 

scale: is a single scalar, pertains to the projected image size, does not affect aspect ratio

 

fit: also does not affect aspect ratio, as aspect ratio remains the same as that of the image when the "Fit textures to part" is selected in Options | Parts menu.

 

I have the impression that when you are saying "fit," that you are talking about manually editing the "Projected image size" (in Smartpaint Properties) with "Preserve aspect ratio" deselected. But on my system, selecting "Fit textures to part" in Options | Parts only scales the image so that one of its dimensions projects to one half of some typical length of the part. For instance, a cube will be painted with four tiles of a square image on each face.

 

I say all this only for clarification of our terms. Now for the point I'm trying to make:

---

Pixels are what an image is made of, but when you say, "What size is this image?" one person might answer, "128 x 128 pixels," and the next guy might say, "It's an 18-inch square tile." Of course, we know that when it comes to texturing a part for rendering, pixels don't count anymore. All we care about is whether the projected size of what is depicted in the image actually matches the real-world dimensions of the part being textured.

 

So IC's current "fit" method, though it can be handy for tiling interesting patterns for cool artistic effects, is not useful when you want to texture, say, shingles on a roof, or planks on the side of a barn. In a case such as these, the pertinent parameters are not the X and Y dimensions of the image in pixels, but rather the X and Y dimensions of the actual physical objects shown in the image. These numbers (you really only need one of them, as the other is readily deduced) are not obvious to the user at texture time. That's why I have proposed keeping them in a registry.

 

In my proposed scenario, the aspect ratio of the image could be altered ahead of time by registering explicit X and Y values (we should probably use "height" and "width" terminology in order to avoid an inferred reference to the global coordinate system). In this system, every registered image would always default to a 100% scaling the moment it is used for either a texture or a bump map. The user could then override this default by either entering a [uniform] scale factor, or by entering explicit dimensions, as we do now. Furthermore, a scene file-specific scale factor could be implemented for each texture, answering your question regarding "linked textures."

(Note: after some thought, a global edit of the image registry (as I mentioned above) would affect every scene file, so that wouldn't be a good solution.

---

NOTE:

After some investigation and thought, I now realize that what I'm talking about can be accomplished at the texture level today, by loading an image into a texture, then using the texture to paint the part (dropping it from a catalog), and maybe this is the best way to leave things. So far I have found myself building textures on the fly by applying the image file manually, in which case I must figure out all of the scaling each time. But I guess all I need to do is take the time to build a texture catalog.

 

So now, referring to your original post:

"My question is should the scale be the default?"

My answer is yes, the scale should be the default.

 

For your questions 1 and 2, I don't fully understand the questions. Feeling a little dense here... could you explain the ramifications more clearly?

 

Thanks for your patience.

[Guest EricFoy]

Another idea comes to mind:

 

What if we had the ability to have a texture (or "material" as it is called in common rendering parlance) remain linked to a catalog texture. That way you could edit the catalog item and all linked textures in the scene would change accordingly. To leave a texture in the scene unchanged, you would first unlink it before editing the catalog items.

 

Of course, changes made to the catalog item would be reflected in every scene containing textures linked to it, so to avoid this (if desired) you would simply unlink one part texture, edit it as desired, then drop the new version into the desired catalog, then drag this new catalog texture onto the desired parts.

 

Wouldn't this nicely address your questions 1. and 2. ?

 

P.S: You might wanna scrap all that stuff I said about an image registry. Sorry.

 

P.P.S: I really think everyone should try to forget I ever suggested anything about an image registry. It suggests a layer of complexity only to attain functionality that is already available.

 

P.P.P.S: Whoever first mentioned that hair-brained scheme about keeping some kind of image registry thing should be banned from the boards.

Edited May 25, 2010 by EricFoy

[Guest svangeldern]

Eric,

 

By the powers invested to me by the IronDudes (none) you are officially banned from this forum.

 

You are also banned from participating in and or wagering on quidditch matches.

 

Steve

[Guest EricFoy]

Nooooooooo! Not quidditch!