[Plugin] Super Drape
-
@tig said:
So maybe ThruPaint is messing with the UV-mapping in a way that SuperDrape can't unravel into a suitable way onto the surface?
Can you use it to reverse engineer the problem after SuperDraping ?The draping proces changed (divided) the mesh in such a way ThruPaint doesn't pick up any quads anymore so using that result in a mess. Trying to figure out some workarounds...
edit: tried copying UV with UV toolkit but didn't work. I guess due to the difference in vertex count.
edit2: exporting the original flat road as 3ds / dae reports: 80 different textures are being made. Importing that 3ds / dae results in 80 different materials for the road. One for each face. Strange..
edit3: exporting the draped UV's to roadkill is no solution either. Even after welding it doesn't look good and individual points can't be moved.
-
Had another go at trying to find some workflow to get roads, rivers, ponds or any textured flat custom shape into a 3d terrain mesh (or actually into any 3d mesh - otherwise I could just as easily buy instantRoad).
I tried copying the edges of a flattened version of the original terrain into the original textured flat road so the number of faces and edges would be the same as in the superdraped road. I hoped I could then use UVtoolkit2 to copy the uv coords of (3) into (2) but it didn't work at all (see result 4).
I wanted to know if there's something strange happening with the UV coordinates so I had a go at ruby and google-searched-copy-pasted some code to investigate them:
ss = Sketchup.active_model.selection @tw = Sketchup.create_texture_writer side = true hash = {} ss.each do |i| next unless i.class == Sketchup;;Face uv_helper = i.get_UVHelper(true, false, @tw) i.vertices.each{|v| p = v.position uv = (side)? uv_helper.get_front_UVQ(p) ; uv_helper.get_back_UVQ(p) uv.x /= uv.z; uv.y /= uv.z; uv.z = 1 hash[v] = [] if !hash[v] hash[v] << uv puts ("ux=" + uv.x.to_s + " uy=" + uv.y.to_s) } end
I hoped for some really strange results but I'm no export on the UV coordinates so I have no idea what I'm looking for. What's strange though is that some faces have the same UV coords but still look different (see picture).
I hope somebody has a clue what to do...
-
This is hopelessly broken. I just keep getting a complaint that the group needs to be above the other group... and no matter how many ways I adjust things it just keeps doing that. Only once did it do anything else, and it wasn't draping. Just added a bunch of extra geometry that roughly corresponded the object I was trying to drape. WOrse, it breaks the ability to create grids.
-
When a plugin like this is hopelessly broken it is usually down to user error.
More infomation on what the problem is would help. Some images or the model to test.
First thing that springs to my mind is you have your model orientated incorrectly, solid blue is up. -
Perhaps if you posted the SKP with it set up in the way you get a fail, then we'd be able to see better what was up.
Also, do you have any Ruby Console output?It should never break anything else...
Are you sure it is not something else that is breaking it?And what 'Grid' thing is 'broken' exactly?
SuperDrape works when one group is placed over another and they are selected in the appropriate order...
Are your axes visible?
Are they set to the default??
etc...Possible issues arise if either of the two groups have very tiny geometry - SketchUp's intersect fails to make edges < ~1/1000th"...
Have you tried using The native Sandbox > Drape ?
If so what happens ??I guess that it is either 'user error' or 'inappropriate geometry'
-
For the last couple days now I've been messing with this to try and get this to work with no luck UNTIL I finally realized all the faces were oriented backwards now that i've gotten passed that setback I've encountered a few more issues and was wondering if I'm doing something wrong still or if SuperDrape isn't capable of doing what I'm looking for. Long story short instead of having a topography mesh or skin I flattened the topo lines, closed the faces, and pulled them all up in 1 foot increments to graphically represent grade. Now here's the issue, when I superdrape my streets/pavements/materials unto the topo group 1) the lines don't drape down the vertical faces like they would if I was using regular drape tool and 2) the materials don't drape down the vertical faces either.
Can anyone help?! I'd rather not flatten the topo group back to a plane and superdrape but the more I mess with it the more it seems that's the best solution. The issue there being the extra hundreds of faces draping the streets onto the topo will create when i go to pull them up in 1 foot increments again. Hence why I was hoping to make the topo, then make the flat streets with materials, and combine them in one easy step. otherwise I'm either spending a bunch of time painting all the verticals or re-pulling all the topo faces.
-
Vertical faces won't get draped/colored.
Meshes with vertical facets are always an issue in many tools.
If you make the face very slightly off vertical it will work...
Of course you could always use sandbox's drape first to get vertical divisions, and then super-drape for the materials [or at least most of them].
You can always edit the mesh group and use the material-browser eye-dropper to sample the adjacent face's material and paint that onto the non-colored faces ? -
Thanks TIG! Because of the workflow I'm adhering to I'm using one foot steps to represent grade at topo lines and modeling a huge area of downtown Milwaukee. To paint the thousands of vertical faces to match it's surrounding color I felt would have taken me a lot longer than flattening the topo, super draping the street/sidewalk materials and then using Fredo's tool to push pull multiple selections at once. This way I just followed the topo lines and selected all faces within each level and boom, vertical faces paint themselves! Thanks again for your help and this amazing plugin!!
-
TIG,
I seem to be well outside the user learning curve here;
Have read ad reread the process for super drape and your more recent suggestion to explode and then re group to no avail.
Am running os 10.11 and skp 2015 pro.it s simple brick pattern image set just over a z axis-distorted rectangular surface
Thanks in advance
Richard/Users/richard/Desktop/Screen Shot 2017-02-19 at 8.47.52 PM.png
-
Fine for me
By precaution subdivide more the Groupe2 !
-
Place the group to be draped vertically above the group that it is to be draped onto.
Run the tool.
-
Pick the [upper] group which is to be draped.
-
Pick the [lower] group which is to be draped onto.
Note:
All faces in both groups must be oriented upwards.
The material[s] in the upper group will be applied to the draped parts in the lower group.
That error-message suggests that you are picking the lower group first, and then picking it again ?
-
-
Yjmls Yog for suggesimg that I had to further explode the drape objects and the potential draped object but that was not the problem. I discovered that the problem was my own lack of patience.
For me at least SD is not immediate but only gradually transfers the material: It first downloads the outline of yhe draped object, then slowly imprints the material content of the draped image onto that outline.. I draped the word "text object" (out of SKP's 3d text tool) onto a simple curved cylnder surface/ ( It took about 30 sec.) The material infilling then followed (It took another 45 sec..and occurred in sequence...Just a heads up for other users who are expecting an immediate transfer .. My SKP pro 15 and memory etc are all otherwise good and as fast as expected when using other elements of skp. -
Doesn't work in v2023
-
It does work on all current SketchUp versions, but after its installation it then has to be enabled in your Extension Manager dialog [once], note that it's also 'unsigned' [because it's so old] and your Extension Manager's Loading Policy therefore needs to be set as 'Unrestricted'...
-
thank you TIG I found it (though why its disabled by default isn't 100% clear to me). I decided to use it in 2023 because for some reason the regular drape stopped to work in v2023 inside groups.
BTW in situation with 2 primitive squares (the lower one is sloped) SuperDrape fails.
P.S. Any chance to make the plugin less restrictive? I mean to work with raw geometry, and as option, to treat the pre-selected geometry as to-be-draped?
-
Move the first group up a little bit above the bounding box for the second group.
-
@dave r said:
Move the first group up a little bit above the bounding box for the second group.
thanks, it helped!
-
I was long time thinking about something including Your drape but even more complicated.. that's why I didn't do it.. is way over me..
I mean like Your drape but somehow remembering the terrain on which it is draped. For landscaping purpose.. You draw in a group Your terrain not to complicated.. than You drape a road lines etc from another group that it is completely flat.. If You see that some area requires some refinement You context click on it .. let say something like "edit base group" You add some details and all updates automatic..
Maybe some way to include eventually push pulls from the draped group.. like to keep the edge of the road and pavement..
and You could draw some additional detail in the flat group and click update.. (automatic update would be way to heavy I guess).
Like I said.. I can make some very simple plugin.. make my toolbar.. but that is way over me.. -
It's already exist. It's called 3ds max with it's subdivide retopo tyconform procedural modifiers.
-
I am having bugsplats everytime I try to use it.
I am trying to superdrape like 100 60x60cm squares on a mesh (which has a street layout)
I need the drape to copy the red color of the squares to the mesh, so I can select all 100 squares draped on the mesh and user a vector push pull to create tree spaces.
Any suggestion on how do fix the bugsplat or another method I could try?
Advertisement