[Plugin] Remove group materials, leave geometry material

xrok1 · 20 Mar 2009, 21:49

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.

Jackson · 21 Mar 2009, 08:25

@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.

xrok1 · 21 Mar 2009, 17:30

@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??

teofas · 24 Apr 2009, 18:53

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!!

sepo · 24 Apr 2009, 21:52

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.

teofas · 24 Apr 2009, 23:33

thx for your quick answer sepo, i apreciated bro!

Jackson · 26 Apr 2009, 08:20

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".

free agent · 2 Jun 2009, 17:56

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...

Matt666 · 2 Jun 2009, 20:52

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...

Pout · 8 Jul 2009, 13:19

is there an opposite of this plugin?
one that just keeps the group/component materials but deletes the geometry materials inside it?

regards

thomthom · 8 Jul 2009, 13:57

@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

EarthMover · 8 Jul 2009, 13:59

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?

thomthom · 8 Jul 2009, 14:03

@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.

thomthom · 8 Jul 2009, 14:07

FYI: I have an imported Revit model that has 777 component definitions and ~2500 component instances. Totalling of about 70-80000 faces. This model takes 1-2 minutes to parse before it opens the render window and begin rendering.
And this model has no material at all - just plain default. If I had group/component materials applied the computer would tie a bucket of brick around itself and jump of the bridge...

EarthMover · 8 Jul 2009, 16:21

Must be other issues. It's really frustrating that there is no parsing progress bar. Or, the ability to have it only have to parse once. Seems like since it is just storing UV data, that as long as you don't move the camera, you should be able to reuse the same data. Nothing is more frustrating than having to wait for every test render.

On another note, I tried to open SS's Snowberry model (which took about 5 minutes to open) and render with VfSU (with no materials)......after 30 minutes of parsing, i just gave up.

thomthom · 8 Jul 2009, 17:10

@earthmover said:

Must be other issues. It's really frustrating that there is no parsing progress bar. Or, the ability to have it only have to parse once. Seems like since it is just storing UV data, that as long as you don't move the camera, you should be able to reuse the same data. Nothing is more frustrating than having to wait for every test render.

But you need to parse the whole lot again anyway to check if anything has changed.

The next version should see some improvements though.

@earthmover said:

On another note, I tried to open SS's Snowberry model (which took about 5 minutes to open) and render with VfSU (with no materials)......after 30 minutes of parsing, i just gave up.

That model is up in the millions in face count isn't it?

Matt666 · 10 Jul 2009, 13:33

Hi all.
Sorry for the delay, I will see what I can do.

m48 · 22 Oct 2009, 05:15

holy shit, it really works!!! you s-a-v-e my a-s-s.
I need to give something in return men, i owe you one,you are my new hero.

chango70 · 27 Jun 2010, 22:41

Do you still need to do this with the new Vray? (v1.488) I seem to encouter problems when with Vray 1.488 after running this script (not 100% this was the culprit)

Cheers

thomthom · 28 Jun 2010, 06:17

@chango70 said:

Do you still need to do this with the new Vray? (v1.488)

No - Only with 1.05.30 and older. The new one might actually be faster if you use group/component materials.