[Plugin] Remove group materials, leave geometry material
-
I have a suggestion for an improvement. An option to make components painted with different materials into unique components.
-
Hi thomthom!
Sorry for the delay! Great idea! O've updated the code.
I've tested it veeery quickly....
The plugin post is up-to-date. -
Thank you Jackson
-
Amazing work Matthieu!
-
Sorry Matthieu, I just ran a test and this isn't working, or at least it's not working at all as I would like. It doesn't create distinct components according to colour as ThomThom suggested- after running it on 3 identical car components which I'd painted different colours it just turned them all blue and they are still intances of the same component. I don't understand the logic behind the new colour choice for default either (personally I don't like ruby scripts to use their own material libraries, as I keep very strict control over my materials libraries, but that's another story). Surely this feature overrides the whole point of the original script i.e. that it replaces the default material applied to geometry within groups and components with the material which has been applied to the groups or component. Now all the geometry with default material applied turns a new global colour, which make the script useless for V-Ray users.
Sorry for the criticism, hopefully you understand it is intended strictly constructively! I am still your number one fan!
-
@unknownuser said:
Sorry for the criticism, hopefully you understand it is intended strictly constructively! I am still your number one fan!
Sorry for the incovenience...@unknownuser said:
Surely this feature overrides the whole point of the original script i.e. that it replaces the default material applied to geometry within groups and components with the material which has been applied to the groups or component. Now all the geometry with default material applied turns a new global colour, which make the script useless for V-Ray users.
You can use this new script as the old... Just select Yes, and default. And it will do the same thing! Or I'm completely wrong
In fact I didn't understand Thomthom's request
Here, the update can replace parent material to desired colour. Or replace the default material when you choose No... If you don't understand, tell me... I have a poor english...Thomthom's request is agood idea... I will see what I can do!
-
Matthieu,
Still not working properly I'm afraid. Despite selecting "Yes" and "Default" 3 differently painted cars all turned red. Can you reattach the original (i.e. pre 17th March) ruby script while you're fixing the new one please? I stupidly overwrote it when I installed your new version and I'll need the old fully-functioning one for work tomorrow!
Thanks again for all your hard work!
-
This is normal your 3 differently painted cars all turned red. I didn't understand thomthom's request (my poor english
)... The last one works like the precedent: It puts comp material on geometry, but it doesn't make different color component unique! No need to re-attach the original.
And I also lost this one
!! However I'm sure this last update can do what precedent version was able to!
A future version will be able to do what thomthom want... -
Ahh, I see... so I can continue using the current ruby script, just as long as I don't have identical components with different materials applied to them.
One further suggestion for the next version though (I bet you wish you'd never started now!)- the Yes/No selection should be set to "Yes" as default or just set up as an "OK?" warning message as it was before, as it's rather irritating to have to change it every time you run the script (which in my case is many times daily). If the end user didn't want to apply the C-G materials to the geometry they wouldn't have chosen to run the script!
I think the warning is sensible though so people know they are applying a permanent change to their entire skp file. -
Did I cause all this? ooops....
p.s. Matt
Inregards toif Sketchup.version[0,1].to_i >= 7. This will break when SU hits version 10. (A bit far of, I know) But instead you can doif Sketchup.version.split('.')[0].to_i >= 7which is future safe.
-
My poor english is the culprit...
Ok, I see... But If you do this :
Sketchup.version.to_i, it works great! -
@matt666 said:
Ok, I see... But If you do this :
Sketchup.version.to_i, it works great!Ah! Cool! Even cleaner!
-
what would be really cool is if you could get this script to work on projected materials.
-
@xrok1 said:
at would be really cool is if you could get this script to work on projected materials.
As projected materials can only be applied to geometry directly (as opposed to groups or comps) they aren't taken into account in Remove C-G.rb's calculations. If you're referring to the fact that VfSU can't read the UV mapping for perspective-skewed materials (i.e. photomatched or manually distorted) that's a whole different problem from what this little ruby was meant to solve. Nevertheless that would be one great VfSU super ruby!
-
i was thinking something more like this>
if i could get the texture to project in these cobblestones components, i could have 36 unique cobbles.
-
I think that would be a different plugin all together.
-
xrok1,
Maybe I'm not understanding your question, but you can easily make 36 unique textured cobbles in SU now. The repeated texture has only been created because you only made one textured cobble group/component and then copied it. If you copy the shape of the cobble first, apply the texture and then make each one into a group or component they will keep their UV mapping relatively rather than locally. If you make sure that this set of groups/components has the same repeat/tile dimensions as your tiled texture you can make a cobbled area as big as you want with a perfect tiling texture and tiling geometry.
Following the logic of applying an updated "Remove C-G" type script to what you're asking for, you would end up with thousands of components, one for every single cobble in your model.
-
I just quickly made a better example, attached, where the cobble geometry actually follows the texture and each set of cobbles (and the moss joints between) is a component which tiles like a jigsaw puzzle. Come to think of it, it would actually be more useful for the sets to be groups rather than components as you can then delete extra cobbles without affecting all the other sets.
-
thanks for the response. this is still the long way of doing it and you have to texture each object individually. what would be nice is if SU would update projected textures when copied. if i make one cobble and project the texture on it, when i make a copy beside it the texture should be projected from that location just like if i moved the original should it not? now if i wanted to lock the texture i could paint the group instead of the individual faces.
i know it dosn't work this way i'm just saying it would be more logical and usefull, otherwise it kinda defeats half the purpose of projected texture. now it should be called "projected texture (if you don't copy)"
maybe projected textures are protected by copyRight laws.
-
@xrok1 said:
thanks for the response. this is still the long way of doing it and you have to texture each object individually.
I just made one large plane with the texture on it, drew the rectangles around each cobble (in your example you could just copy/array them), grouped the joints in between (as one large group), then pushpulled each cobble up and grouped them. Everything was textured from the start, the only actions were to make the geometry, so it only took about 10 minutes.
@xrok1 said:
if i make one cobble and project the texture on it, when i make a copy beside it the texture should be projected from that location just like if i moved the original should it not?
If it was just geometry and not a group or comp then that is exactly what would happen, but the fact that groups and comps "fix" their UV mapping on creation is essential to texturing in SU. Probably 90% of the groups and components I use have a texture which is mapped exactly to the geometry- e.g. if I have a png textured tree on a flat plane when I copy it to another location I don't want the UV mapping to move, I want it fixed locally.
@xrok1 said:
now if i wanted to lock the texture i could paint the group instead of the individual faces.
Painting groups is exactly what this ruby script is trying to avoid and what causes V-Ray problems via the ruby API. Besides, when you paint a group you lose the ability to manually position UV maps on individual faces which makes rendering pretty much impossible. Nevertheless, being able to choose whether UV mapping is applied locally or globally would be a useful addition to SU- someone did suggest a toggle "lock/unlock global UV" for groups so when they're copied or scaled their UV mapping would stay global. The catch is that 2 instances of a component with different UV mapping are no longer identical, so they either have to become unique components (which is what ThomThom is requesting this ruby to automate) or just plain old groups. It would be neat to see this added to SU group attributes, but at the moment I just explode and regroup to get around this.
Advertisement