[Plugin] Remove group materials, leave geometry material
-
@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.
-
@unknownuser said:
xrok1 wrote: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.
it dosn't work this way! try it. at least on my machine the raw geometry is copied to a new spot with the same texturing even though it says 'projected' it needs to be repainted with projected material again to get it right??
-
hi to all. i may sound stupid, but i just install vray for skp 1.5 and i use skp 7, but i dont know exactly how to use this plugin, please if some one could tell me ill be very gratefull...thx in advance...by the way its true that the ne version of vray for skp takes too much time to star rendering even 20 min,,,its crazy!!
-
Teo. It is very simple. Just locate it in your plugins, click on it, accept delete (although it does not delete anything) and that is all. It speeds up parsing in Vray 1.5.
-
thx for your quick answer sepo, i apreciated bro!
-
Not a stupid question at all, but believe me- once you start using ruby scripts with SU, you won't be able to stop as they can increase SU's functionality many many times over.
Just save the .rb file to the "Plugins" folder in your Google SketchUp program files. The next time you open SU it will be accessible under the "Plugins" menu under the name "Remove C-G Materials".
-
hi on the front page Mat666 says the new version has all the suggested improvements any way someone could post a features list, to save people (me) having to read through all 5 pages and descern what exactly was implemented
...lazy freeloaders...
-
Sorry, I have no time to work on this plugin...
And components & groups easily generates lots of bugsplats... It's very hard to work with...
Give me some time, I will certainly have a moment to improve it... -
is there an opposite of this plugin?
one that just keeps the group/component materials but deletes the geometry materials inside it?regards
-
@pout said:
is there an opposite of this plugin?
one that just keeps the group/component materials but deletes the geometry materials inside it?regards
It does now: http://forums.sketchucation.com/viewtopic.php?f=180&t=17587
-
Anyone notice a REAL dramatic difference in parsing after running this script? Whenever I have a really long parse, I'll run this script, but it never really seems to speed things up. Is it just me?
-
@earthmover said:
Anyone notice a REAL dramatic difference in parsing after running this script? Whenever I have a really long parse, I'll run this script, but it never really seems to speed things up. Is it just me?
Yes, there's a VERY big increase in parsing time.
At the end of the script it tells you how much was replaced - what does it tell you? It could be that you are running into other issues. Lots and lots of groups and component definitions eats time as well, more if they are deeply nested.
But groups/component materials eats the most of the time.The reason it's so slow is that when VfSU runs into group/component materials it has to internally create a new copy of that object and in order to get the proper UV mapping it has to apply all the group/component material to the faces contained inside - then afterwards restore it. And that takes an insane amount of time.
Advertisement