[Plugin] Super Drape
-
Could I ask for some help? I'm trying to drape a textured road on a terrain mesh. Using Super Drape the resulting mapping coordinates are messed up somehow.
Already checked: units, regrouped both, edge inspector results in no errors, face normals are ok, removed smoothing and all edges are visible. I have no idea why it doesn't work.
Any help would be appreciated.
kind regards, Max
-
I confirm I get similar results.
The UV-mapping of the upper faces' textures should be transferred to the facets in the draped version, with adjustments for their relative normal angles: but clearly this is not happening...I will investigate...
-
@tig said:
I confirm I get similar results.
The UV-mapping of the upper faces' textures should be transferred to the facets in the draped version, with adjustments for their relative normal angles: but clearly this is not happening...I will investigate...
Great Tig! Just wondering, the terrain uses projected textures - cause of problem maybe?
-
It may be a projected texture issue...
How did you apply/edit the textured 'yellow stripe' material on the 'flat' faces ?
I found that if I added the material afresh and used Texture and/or My Texture Tools Plugin to adjust its rotation/position I could then get it to SuperDrape acceptably - see the first 6 facets in the screen-shot - I defaulted the next two facets to show the differences between my effort and your original
-
@tig said:
It may be a projected texture issue...
How did you apply/edit the textured 'yellow stripe' material on the 'flat' faces ?I applied the texture using Fredo's ThruPaint. By doing so the mapping for the entire road is aligned to the curves of the road in just 2 mouse clicks.
@tig said:
I found that if I added the material afresh and used Texture and/or My Texture Tools Plugin to adjust its rotation/position I could then get it to SuperDrape acceptably - see the first 6 facets in the screen-shot - I defaulted the next two facets to show the differences between my effort and your original
Tig, thanks for your time and effort. This method sounds a bit more time consuming. Will try as well.
-
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 ? -
@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'...
Advertisement