[polynurb]

Hi

This tool is for NURBS models, and you will need Rhino 5 sr3+ and an installation of the latest grasshopper.



surfaceRemapper.gh

there has been discussion about the RealScale feature in the past.
Keeping it short: it has it's limitations but is still useful to a certain extend.

What i am posting here is not a "maxwell-realscale" replacement, but a tool that could help us Rhino users to master this problem by means yet impossible.
in theory i have been thinking before about how a more powerful automated texturing tool could look like and now with the use of grasshopper, built a first prototype that partially solves Step 1 in a series of goals:

I am posting this so that anyone interested can join discussing what we can do about it from the rhino/GH side and to test/modify/improve the Grasshopper setup i attatched. there is still a way to go....

aim: using realscale but based on surface UV mapping

step1: determination of orientation in space. correcting U and V surface directions so that +V (top edge of texture) will point "upwards". this is eg. useful for a wall polysurfaces, and will synchronize all faces to the same orientation. flat faces (in xy plane, like ceiling and floor) are not modified. However this works for surfaces of any orientation, and will always scan or the steeper inclination (start>end iso U or start>end iso V) towards world unit Z vector. As you know, after exploding a polysurface, directions are usually random so this can be very useful for a set of tasks, see the images below on how this affects surfaces with arbitrary orientation.






this is functional in the .gh file i attatched. but there is one little problem i can't solve atm:

i am trying to use this litte VB script posted by D.Rutten here here to do the final UV alignment. However, A outputs an invalid Brep and i don't know why. If someone knows how come, let me know!!

Code: Select all

  Private Sub RunScript(ByVal S As Brep, ByVal U As Boolean, ByVal V As Boolean, ByVal F As Boolean, ByRef A As Object) 
    If (S Is Nothing) Then Return
    If (S.Faces.Count > 1) Then
      __err.Add("Polysurfaces are not allowed")
      Return
    End If

    Dim face As BrepFace = S.Faces(0)
    Dim srf As Surface = face
    If (U) Then srf = srf.Reverse(0)
    If (V) Then srf = srf.Reverse(1)
    If (F) Then srf = srf.Transpose()

    Dim idx As Int32 = S.AddSurface(srf)
    face.ChangeSurface(idx)
    S.CullUnusedSurfaces()

    A = S
  End Sub 

so i am using a C# version of it, but the code only works on surfaces, so trim is lost.
I don't know how to extract the Brep Face in C# and work on that in order to keep the trim.

right now i am using this, so all the surfaces you input will be untrimmed:

Code: Select all

  private void RunScript(Surface srf, bool swapU, bool swapV, bool swapUV, ref object A)
  {

    if(swapV)  srf = srf.Reverse(1);
    if(swapU)  srf = srf.Reverse(0);
    if(swapUV) srf = srf.Transpose();


    A = srf;
  }

once this is solved>
step2:

after the aligment, edge lengths of all surfaces will be extracted and compared. (check is performed on eg.mean length of untrimmed edge pairs)
the resulting differences are calculated back to respective U and V tiling values. THIS is where the actual "RealScale" is applied with all the benefits of keeping UV surface mapping.

technically i could build this in GH, but i don't see any Methods exposed in Rhino Commons which would let me set tiling, offset or UVW rotation values. Also outputting to a certain mapping channel would be very helpful. I can't even get there by rhino's command line.
however i have been following this thread and i think there is help on the way.

in any way this is rather sophisticated stuff, and i won't be able to solve the scripting part all by myself. so this will take some time... but i am pretty confident this will be possible in the close future

IF this is solved:
step3:
we can think about further options like rotating W or offsetting textures automatically;
it should be possible on a polysurface to define common edges, and to have offset computed in a way that no "jump" in a pattern is visible at the join... and so on.

exciting isn't it ?

please feel free to comment and give feedback or suggest new ideas!

cheers,

Daniel


ps. beware any bugs!

[JDHill]

Pretty cool, Sir. I would like to help, but I am pretty busy these days, and have only dabbled with grasshopper.

[polynurb]

I am pretty busy these days

getting some v3 tan, right?

[JDHill]

[kami]

That sounds very interesting. Sadly my scripting capatibility is very limited, but I'm working on improving it whenever I have the possibility. In the meantime I'll try to ask our "scripting expert"

To me the realscale feature worked perfectly the way it did a few patches ago (where you had the easy possibility to tweak it with the help of a box mapping of 1x1x1m and even randomize this if necessary). So it was also possible to just select all your walls and give them a 1m box mapping so that the orientation of the texture was always right and you wouldn't see a jump in the texture even if you had multiple objects touching.

Sadly with the latest patches, things got a little more complicated.

[polynurb]

That sounds very interesting. Sadly my scripting capatibility is very limited, but I'm working on improving it whenever I have the possibility. In the meantime I'll try to ask our "scripting expert"

hey that would be great. As you pointed out I am not a code guy either. I digged my head into the grasshopper stuff by now though and it is really just small code snippets that are missing for the first step to be complete.
I posted in a few places in the rhino forum, no replys yet. it is a bit chaotic over there with all the changes to the NG and new Ning discourse.
*

i see what you mean about realscale, but i have never used it much myself. i always found it quick to have a cubic mapping (or several) that i could quickly copy between objects.

the idea about the GH setup is that walls of all type would work, bent, curved, tilted without distorted projection or sudden discontinuities.

and in the best case you get a set of surface projectors to apply textures>

one to use for dirt/environmental maps (for treating edges)
one with the correct tile size according to your specs (tiling will start clean at the floor/wall corner)
one where "tiling" Nr. is always a whole within the visible surface domain, even if the surface is trimmed, so that a texture tile is never split.

let's see where it gets!


btw.

have you ever tried this :http://www.grasshopper3d.com/group/scarab

very nice, imho. and working good so far. in fact i just created 300 unique materials following a color gradient...

[JDHill]

To me the realscale feature worked perfectly the way it did a few patches ago (where you had the easy possibility to tweak it with the help of a box mapping of 1x1x1m and even randomize this if necessary). So it was also possible to just select all your walls and give them a 1m box mapping so that the orientation of the texture was always right and you wouldn't see a jump in the texture even if you had multiple objects touching.

Sadly with the latest patches, things got a little more complicated.

I don't really understand, mainly because what you describe is not even a real scale workflow, from the plugin's point of view; when you use explicit mappings, the only effect RS has is to cause Maxwell (at render-time) to interpret your texture tile values in reverse, where if you are indeed generating 1m cubic UVs for objects, a tile value of 2 would mean, rather than fitting 2 copies of the texture into the space, that 1/2 copies would be fit, resulting in a real 2m tile size, based on your 1m cubic UVs. The only factor likely to cause a problem here would be neglecting to remember that explicit mappings begin on channel 1.

Since your perception appears to differ from this, I will just run quickly through the logic: there are only two main variables of which to be aware: a) whether you are using explicit mappings, and b) which texture channels you are using. If you are using explicit mappings, these UVs go on texture channels 1 and up, and are exported unaltered by the plugin. The UVs written for channel 0 depend on whether RS is enabled in a channel 0 texture used by the object in question. If RS is enabled, the plugin generates appropriate cubic UVs for the object, according to its rotation values, as set in obj props > Maxwell. Otherwise, UVs on channel 0 for this object will be a) the "viewport" UVs, if they are found to exist, or b) the channel 1 UVs, if those are found to exist. By saying that it worked differently before, I can only assume you refer to one plugin build where the code was being more strict, and that last clause (falling back to channel 1 UVs) was not true, but this was only temporarily the case.

And Daniel, regarding Scarab, I have to remind that this is as unsupported as it is cool -- and it is absolutely cool.

[Ha_Loe]

Hey,

just wanted to say, that I had a quick glance at the code and tried to quickly adapt the C# script to BReps.
You can easily access the BRep faces by enumerating through the BRep.Faces collection. You get a BRep face, which is a Surface with trims.

There's two problems with BRep Faces
a) Face normal need to point "outside". The normal direction is determined by U and V direction. So you can't just independently flip any U or V.
b) From this quick exploration, it seems that you cannot just dig down to underlying Surface and flip it. The result if .Reverse() or .Transpose() are new Surfaces. So I'd need to remove the old Face from the BRep and add the flipped one. Looks like you can only add Surfaces OR Trims to a BRep and I have no idea how Rhino might adjust UVs to suit its internal conditions...

Soon as I come around to code and test this stuff, it will make it into the Scarab.Generics.

[polynurb]

Hi Ha_Loe,

thanks for taking a look!

and yes you are absolutely right about me forgetting about normal direction... and I didn't correct it yet.
I am scratching the code/scripting side of rhino from grasshopper, but i am having my trouble&lack of time to dig through the online documentation.

But I have implemented other experimental features like setting Repeat length for tile values in U and V and an option to snap length to the closest full tile along a given edge. alternatively one can force "brutelentgh", which will then start to count at U/V 0.0

shrinksmall panels shrinks non full (cut)tiles to get the full texture on the surface (eg. of you need "mortar" along the surface edge)

a reason I never came back here were other problems I had with GH vs Rhino:

-sometimes a tile corner can get very very close to an edge, where i can still split the surface correctly in rhino, in GH sometimes a small piece of surface will be skipped, destroying my list management, and deleting wrong faces...

-when testing with rhino geometry from arbitrary sources, I sometimes see faces reverse when exploding&shrinking in GH vs exploding&shrinking in Rhino. but i didn't try to follow this bug in the forums..

- problems with accessing UV mapping parameters via C# or vbscript or even the commandline!!

you can download the new experimental GH definition here (bake the polysurface not the mesh to retain UVs correctl.. it is a v5 bug)

you can read about the bugs/limitations here

http://discourse.mcneel.com/t/accessing ... 2?u=dk2079

http://discourse.mcneel.com/t/bug-unpac ... 9?u=dk2079


Frohes Fest!

daniel

[Ha_Loe]

Hey Daniel,

hope you had a happy holiday.

I have implemented other experimental features like setting Repeat length for tile values in U and V and an option to snap length to the closest full tile along a given edge. alternatively one can force "brutelentgh", which will then start to count at U/V 0.0

will also have a look into those

shrinksmall panels shrinks non full (cut)tiles to get the full texture on the surface (eg. of you need "mortar" along the surface edge)

a reason I never came back here were other problems I had with GH vs Rhino:

-sometimes a tile corner can get very very close to an edge, where i can still split the surface correctly in rhino, in GH sometimes a small piece of surface will be skipped, destroying my list management, and deleting wrong faces...

-when testing with rhino geometry from arbitrary sources, I sometimes see faces reverse when exploding&shrinking in GH vs exploding&shrinking in Rhino. but i didn't try to follow this bug in the forums..

Could you please provide a sample of this happening? I did some test runs but never came across this particular problem.

- problems with accessing UV mapping parameters via C# or vbscript or even the commandline!!

Still having my own problems here. Custom mapping is a fairly recent addition to Rhino an doesn't seem to be fully exposed in RhinocCommon. Thank you for the Discourse links. Will see what I can do...