Can we improve ExtrudeEdgebyRails? (add options)
-
I am 'Mr EEbyRails'.
I am already aware of your ideas about mesh facet minimizing, from other threads - my initial idea was to keep the mesh as 'smooth' as possible by sub-dividing the opposing rails' edges equally.
It's still best in terms of a 'smoothed' mesh, BUT I know that making a mesh with 100 times more faces just because the edge-count is a little uneven seems pretty unreasonable...
Still best to keep the opposing edge-counts related...
I am looking at ways of offering 'options' - e.g. if opposing edges are equal or simple multiples then 'no options' - if they are not 'equal' then a dialog giving options - telling you the number of edges required to 'smooth it' OR take option to make main mesh even and edges 'from a point' to even up the rest as you have suggested...EEbyRails v2 with Initial-Profile, Rail-1, Rail-2 and Melding-Profile*** is going well - the second profile*** you choose [or re-pick the first one to make the mesh as made currently] means the mesh profile is 'melded' along the rails between the two forms - allowing a predetermined start and end profile - a 'lathe' along rails if you will...
Watch this space... -
One thought I've had on this TIG is to redefine their rails with some algebra using a curve of best fit method. There are many out there to choose from. They the user could specify how many segments they want added, regardless of how many are actually there. Of course then the problem becomes that the reails are only approximating the rails they supplied, but it is a nice wat to smooth things out.
Chris
-
TIG,i think i read that you get the same number of edges by multiplying the number of segments in each edge to get a common multiple. If this is the case im sure itd be easy enough to improve by finding a smaller common multiple.
i.e. edge a has 3 segments, edge b has 6 segments, so common factor = 6 rather than 18.
Apologies if im just imagining that you wrote that
-
It does take the smallest so 6 and 12 uses 6 -you can't go smaller than that for one set of edges as it might form other geometry...
However, 6 and 13 has nothing except 6x13= 78 !
we could go 12 and make the odd 1 taper to zero at one end, bit this affects the smoothness of the mesh... -
Fair enough.
-
@chris fullmer said:
One thought I've had on this TIG is to redefine their rails with some algebra using a curve of best fit method. There are many out there to choose from. They the user could specify how many segments they want added, regardless of how many are actually there. Of course then the problem becomes that the reails are only approximating the rails they supplied, but it is a nice way to smooth things out.
Chris
Approximating a curve only works if that 'curve' is something 'arithmetical' BUT a curve can be any collection of 3D edges in a 3D Polyline...
-
I now have v2 of EEbyRails working - in this version you pick 2/3/4 curves - the Profile, then Rail-1, then Rail-2 [which could also be Rail-1 again] and then a 'Melding-Profile' [could be the Profile again]...
This 'Melding-Profile' lets you dictate the end form/location of the mesh as well as the start derived from the Profile - effectively allowing a 'Coons mesh' from 4 defined paths, with the mesh 'morphing' between them all...
I am going away for a few day but then I plan to issue v2 early next week - however, I haven't addressed the segmentation matching of Rails/Profiles yet - any comments before I commit would be welcomed... -
Great news TIG. Have you tried it on Jeff's "impossible" scenario yet?
-
What about number of segments of each part?
Must be equal for more speedy result or not important as taken from existant between neighbour forms? -
Great news TIG !!!
-
I moved this into the developer section. Sorry for any confusion that might cause - but we're trying to keep the Plugin section an index only.
-
Looks very promising and seems to me that it would be easier to use and be more predictable.
Thanks, TIG for all your hardwork. What will 2010 bring? Hard to imagine.
John -
Edit first post
-
The principal problem is avoid cracks between each existant sides!
-
@unknownuser said:
The principal problem is avoid cracks between existing sides!
The good news is that EEbyRv2 - yet to be unleashed - ensures that the 2 rails and 2 profiles selected are kept so now there are no 'cracks'; however, the number of facets increases dramatically with unmatched segment counts - especially if the rails AND profiles have unmatched segment counts - especially if there's no common factors.
equal segment-counts for rails + profiles =
5&5 & 5&5 =>> 5x5 = 25 =>> 50 facets [remember that quads are triangulated so we need to x2]
10&10 & 10&10 =>> 10x10 = 100 =>> 200 facets [x2 the mesh edges =>> x4 the mesh facets]
Paired segments with a common factor increase by a bigger amount, but still not too unwieldy - here it's x4 for a mesh that has x2 the edge segments =
10&5 & 10&5 =>> 10x10 = 100 =>> 200 facets [same number of mesh facets from far fewer mesh edges]
BUT a similar segment-count but with no common factor give enormously faceted meshes =
10&9 & 10&9 =>> 90x90 = 8,100 =>> 16,200 facets !!!
However, this subdivision method WILL give a properly 'smooth' mesh.
However, there is an alternative algorithm that I am trying to incorporate, which takes the segment count of the most segmented rail/profile as the maximum and projects back 'triangulated wedges' of mesh to a repeated vertex position on the rail/profile with the fewer segments, these 'wedges' will be positioned as evenly as possible along that rail/profile.
I'll probably introduce an extra warning dialog if the facet-count gets above a certain limit - say ~1,000 - which will tell you that it could take some time to make a 'perfect mesh' because you have [stupidly] made the rails/edges with awkwardly uneven segment-counts: and then offering you the chance to 'Cancel' and fix it manually & retry, or answer 'No' to go for the quicker [but simpler and less perfect] mesh, or 'Yes' to carry on as you are and wait for the very faceted mesh to finish processing... zzzzzzzzzzzzzzzzzzzzz.
I hope to have something published early this coming week...
Merry Christmas! -
It's not an easy thing to convert an box modeling prog to a nurbs one
Happy new year and see you the next one -
TIG,
I am wondering if, through your recent experimentation with different algorithms for your "railing" scripts, that a better means for creating a terrain from contours could be developed (v.s. the sandbox method which often requires so much time consuming and tedious cleanup)?
John
-
-
@unknownuser said:
tig wrote : However, there is an alternative algorithm that I am trying to incorporate, which takes the segment count of the most segmented rail/profile as the maximum and projects back 'triangulated wedges' of mesh to a repeated vertex position on the rail/profile with the fewer segments, these 'wedges' will be positioned as evenly as possible along that rail/profile.
what do you think about :
lot of faces may be created, would you try the method of distribution of wedges whitch decrease the number of created face?
|_no "continue whit classic algorithm"
|_yes "open another dialog box"
_|_how would you like to distribute the wegdes
__|_from start "all from start to middle of rail"
__|_from end "all from middle to end"
_| homogeneous "..."
_|_ok
_|_canceldo you think is a good way?
EDIT : is not a good way, i was thinking about low difference between segments's rails, but dont works for big difference ...
merry christmas to all, joyeux noel zot toute
over 30Β°C (86Β°F) for christmas do you believe that ? -
hi Tig,
just a thought, I and it seems quite a few people use fredo's polyline segmentor before using eebyrails, loft, blend, etc..
so, would it be possible to simply call up that tool from within EER2 if a potential problem is found?
john
Advertisement