diseño paramétrico con Grasshopper: días 16, 17 y 18 de noviembre. Curso de iniciación a Grasshopper. Para seguirlo no se requieren conocimientos previos específicos. El objetivo de este curso es tomar contacto con Grasshopper, entender cómo funciona y empezar a fabricar y editar geometría con él. Más información y programa detallado del curso. - MÓDULO II: curso de diseño discriminativo con Grasshopper y análisis ambiental con Ecotect: días 23, 24 y 25 de noviembre. Se tratarán componentes avanzados de geometría y gestión de datos, así como soluciones evolutivas de optimización del diseño con Galapagos, y conexión con Ecotect. Más información y programa detallado del curso. - MÓDULO III: curso de diseño iterativo: scripting con Grasshopper en C#: días 30 de noviembre, 1 y 2 de diciembre. Curso de "scripting" con Grasshopper y Processing, donde se tratará de modelado recursivo con C# y RhinoCommon en Grasshopper. Formadores Los cursos están conducidos por Authorized Rhino Trainers: puedes comprobar nuestros tres años de experiencia, más de 30 cursos de Grasshopper y 300 alumnos en nuestra página web. Material El material de los cursos ha sido elaborado íntegra y exclusivamente por nosotros para estos cursos: - Manual de ejercicios de Grasshopper nivel I - Manual de ejercicios de Grasshopper nivel II - Manual de ejercicios de scripting en Grasshopper con C# Formato Cursos intensivos con duración de 18 horas con el siguiente horario: - Viernes: 17-21h - Sábado:10-14h, 16-20h - Domingo: 11-14 h, 16-19h Grupos El número de asistentes está limitado a un máximo de 10 personas para garantizar la calidad de la enseñanza y a un mínimo de 4 personas.…
Added by Miguel Vidal at 8:40am on August 30, 2012
about it.
2. Nick's comment below got me thinking about unit testing for clusters. Being able to work will data flowing in from outside the cluster or having multiple states to test against could be really cool. Creating definitions that were valid across a general cross section of possible input parameters was a significant issue for us. It was all too easy to write the definition as if we were drawing (often we were working from sketches) and then have it fail when the input parameters changed slightly.
4. I wasn't thinking about threading the solver itself. I was thinking along the lines of some IDEs that I've seen which compile your project while you type it. I know that threading within components and at the rhinocommon-level is a freaking hard problem that has been discussed at length already. (although when, 5-10 years from now, it's finished it will be very cool)
Let's say the solver is threaded and the canvas remains responsive. As soon as you make a change to the GH file, the solver needs to be terminated as it is now computing stale data.
What if the solver was a little more atomic and like a server? A GH file is just a list of jobs to do with the order of the jobs and the info to do them rigidly defined - right? The UI could pass the solver stuff to do and store the results back in the components on a component by component basis (i have no idea what the most efficient way to do this is in reality - I'm just talking conceptually) this might even allow running multiple solvers to allow for at least the parallelism the might be built into a given GH file to be exploited (not within components but rather solving non-interdependent branches of components simultaneously). This type of parallelism would more than make up for the performance hit you alluded to for separating the UI and the solver (at least for most of the definitions i write).
I was imagining a couple of scenarios:
a) Writing a parallel module: solver starts chewing away - you see it working - you know it's done 1/3 of the work - if you have something to do at that point you could connect up to some of the already calculated parameters and write something in parallel to the main trunk which is still being solved.
b) Skipping modifications: you need to make a series of interventions at different intervals along a section of code. Sure you could freeze out that bit of a section of down steam code and make modifications so you can observe the effects more quickly. Unfreeze a bit more and repeat etc. etc. until your done and then unfreeze that big chunk at the end to make sure you haven't blown anything up. Just letting it resolve as far as it can while you sit there waiting for inspiration seems a lot more intuitive to me though.
On a file which takes 15 minutes to solve that's no big deal, but you certainly don't want to be adding a 20 millisecond delay to a solution which only takes 30 milliseconds.
You also wouldn't notice it at that point :-) perhaps for things where it would really make a difference, like Galapagos interactivity, it could be disabled - or could the existing "speed" setting just digest this need? Since the vast majority of time that Gh is solving is on files under active development not on finished code, i think qualitative performance is probably more important that quantitative performance (again with cases like Galapagos needing to be accommodated). In our case the code only had to "work" once since its output went to a cnc machine to make a one off project and it didn't really matter if it took 15 seconds or 15 hours for the final run.
Lastly, I have no way to predict how long a component is going to take. I can probably work out how far along in steps a component is, but not how far along in time.
that's ok, from a user point of view, just seeing a percentage tick along once in a while would be nice reassurance that the thing is just slow and has not, in fact, crashed. Maybe there could be two modes of display: the simple percentage version for unpredictable code and, for those of us able to calculate the time taken for our algorithm based on the number of input parameters, a count down in seconds or minutes or whatever.
I think a good place to start with these sort of problems is to keep on improving clusters, ... etc etc
i totally agree.
…
Added by Dieter Toews at 7:53pm on September 4, 2013
) membrFP.Faces[0], // start/quide surface: going from DC to NY via LA uSpans, // obvious vSpans, // obvious true, // trim outer loop. Fails in most of cases. NOTE: inner loops ARE NOT treated false, // tangency 1.0, // point spacing patchFlexibility, // flexibility: use a generous value around 50 surfPullFactor, // surface pull factor (this needs some investigation) fixedges, // get 4 false values you stupid method, like that? 0.2); // tolerance - be generous: we are talking about tissues here not NASA sourced things
Do you know of a generic container in Rhincommon I can store geometry form meshes, breps and curves to points? That's what I seem to need to get around the IEnumerable error.
I have to figure out how to format the Boolean array in Python. Ah, parenthesis worked!
P = Rhino.Geometry.Brep.CreatePatch(CURVES_CONTAINER, Starting_Surface[0], 10, 10, True, False, 10, 30, 0, (False, False, False, False), 1)
At long last, only to find out it won't work right, as in no setting of flexibility will affect it at all?!
Tolerance has a sudden crazy effect if I turn it way up, like a piece of paper bending up opposite corners and it no long is trimmed, but flexibility is dead. I used your same values and same curves for everything. Yes, all the curves are participating, if I bake them and move them around.
My Patch is broken. Weird. Is there magic with the starting surface? I made a naive assumption just a plane would do. Yet you seem to be using your simple CreatePatch results for this?
Ah, the second CreatePatch command type that takes only a surface gives the same thing, nearly. You need a starting surface at all?! They said you could now leave that out as of Rhino SR10 by using Null, but Null or Nothing gives an error. How do I make a null? In Python it's None, as in just entering None into the Rhinocommon command or assigning a variable to None.
Now I have a patch!
But your's is more expressive, more crazy, like your starting surface is greatly influencing it to have extremely extended feet, whereas mine works like a normal patch, as if you were trying to smooth over things. And indeed your surface pull slider makes it more obvious you chose a specific starting surface attached to one of the curves. My starting planes had no such effect, earlier.
With such a starting surface to bias the results I get the same thing finally, indeed, good to know what that does, I never knew from using the command in Rhino.
Why did my use of a plane shut this down so badly though?! Crazy command.
I've enclose a working script for the record.…
Added by Nik Willmore at 12:47am on February 26, 2016
m
-Area of blue line: min. 80% of the rectangel a x b
-Max. hight h of the top point: h,max = a
-Min. Volume between rectangel a x b and membrane: 500 m3
Can anyone help me?…
her people) a tremendous amount of time creating them by hand. Dog Treat was far from perfect, however it was good enough to use almost daily.
Three years is a long time. Since 2016 my Gh knowledge has expanded and I’ve seen how dodgy some of the scripting is. With this in mind I started work on a new build. Many things have been tweaked and some things have been rebuilt from the ground up.
Everything has been designed to be leaner and be a general solution to the problem of creating dog bone corners on geometry for quick, efficient and safe CNC fabrication.
Some of these things are:
Adding prompts about user geometry to make them aware about open curves, varying curve heights and if their geometry had been altered (mostly removing unnecessary points on curves).
Smooth Transfers. If you’re in a rush and need to speed through cutting, smooth transfers mean that a lead in geometry is now created alongside the actual dog bone arc. This means the router bit doesn’t have to come to a minute stop at every corner. This is turned on by default.
Acute Angle Condition If the angle between the two curves adjacent to a dog bone point is acute, previously the dog bone corner was useless. This was because the distance between the end points of the dog bone arc were less than the diameter of the router bit. There are many ways this condition could be addressed. I chose to circumscribe a larger arc based on the original angle between the adjacent curves. While it removes more material from the corner, it minimises tool wear and any potential for material to burn.
Single Curve A single curve can now be input into Dog Treat. It will be output with both internal and external treatments.
I’ll continue to update Dog Treat as the need arises, it’s become somewhat of a hobby now. Maybe one day it will become part of a Plug-in… once I learn to code it though!
Happy Treating!
Hi Everyone,
Here's a tool I've been working on for the past 4 months or so in my free time. It's a dog bone corner generator, however it's a little different to some of the existing ones. It's designed to be used for large amounts of geometry and as such, it avoids using any curve boolean operations that are computationally taxing. You don't have to split your curves up into internal and external lots either, it works it all out so you can be lazy. I've also incorporated Lunch Box's Object Bake Component for a one click operation that bakes geometry back out to Internal and External profile layers.
Let me know how it goes, will update where necessary.
Best,
Darcy
Change Log
06/11/19 - Version 2.0 SECOND DINNER - Rebuild
29/09/17 - Version 1.3 - Now with smooth corners option, True for smooth default/False for original
18/05/17 - Version 1.2 - Now includes variable angle domain input (defaults at 90°) for angled corners
13/11/16 - slight change to enable acceptance of very large interior curves
…
Added by Darcy Zelenko at 8:44pm on November 9, 2016
.
Things have been working swimmingly in many areas of the plugin, but one particular problem has been tough to solve. I have two components that are trying to read/write to the same memory at the same time, causing Rhino exceptions and crashes.
The conflicts appear to be happening between two components -- one is a "Layer Events Listener" that reports essentially what type of layer event just happened. The other is a "Set Layer Visibility" component that toggles the visibility of a list of layers.
The code:
public class LayerTools_LayerEventsListener : GH_Component { /// <summary> /// Initializes a new instance of the LayerTools_LayerListener class. /// </summary> public LayerTools_LayerEventsListener() : base("Layer Events Listener", "Layer Listener", "Get granular information about the layer events happening in the Rhino document.", "Squirrel", "Layer Tools") { }
/// <summary> /// Registers all the input parameters for this component. /// </summary> protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager) { pManager.AddBooleanParameter("Active", "A", "Set to true to listen to layer events in the Rhino document.", GH_ParamAccess.item, false); pManager.AddTextParameter("Exclusions", "E", "Provide a list of exclusions to stop reading specific events (Added, Deleted, Moved, Renamed, Locked, Visibility, Color, Active).", GH_ParamAccess.list); pManager[1].Optional = true; }
/// <summary> /// Registers all the output parameters for this component. /// </summary> protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager) { pManager.AddBooleanParameter("Initialized", "I", "Whether the listener changed from passive to active.", GH_ParamAccess.item); pManager.AddTextParameter("Document Name", "doc", "Name of the Rhino document that is changing.", GH_ParamAccess.item); pManager.AddTextParameter("Layer Path", "path", "Path of the modifed layer.", GH_ParamAccess.item); pManager.AddIntegerParameter("Layer Index", "ID", "Index of the modified layer.", GH_ParamAccess.item); pManager.AddIntegerParameter("Sort Index", "SID", "Sort index of the modified layer.", GH_ParamAccess.item); pManager.AddTextParameter("Event Type", "T", "Type of the modification.", GH_ParamAccess.item); pManager.AddBooleanParameter("Added", "A", "If the layer has been added.", GH_ParamAccess.item); pManager.AddBooleanParameter("Deleted", "D", "If the layer has been deleted.", GH_ParamAccess.item); pManager.AddBooleanParameter("Moved", "M", "If the layer has been moved.", GH_ParamAccess.item); pManager.AddBooleanParameter("Renamed", "R", "If the layer has been renamed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Locked", "L", "If the layer locked setting has changed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Visibility", "V", "If the layer's visibility has changed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Color", "C", "If the layer's color has changed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Active", "Act", "If the active layer has changed.", GH_ParamAccess.item); }
/// <summary> /// This is the method that actually does the work. /// </summary> /// <param name="DA">The DA object is used to retrieve from inputs and store in outputs.</param> protected override void SolveInstance(IGH_DataAccess DA) { bool active = false; List<string> exclusions = new List<string>();
DA.GetData(0, ref active); DA.GetDataList(1, exclusions);
RhinoDoc thisDoc = null;
bool initialize = false;
string dName = null; string activePath = null; int layerIndex = -1; int sortIndex = -1; string eventType = null; bool added = false; bool deleted = false; bool moved = false; bool renamed = false; bool locked = false; bool visibility = false; bool color = false; bool current = false;
if (active) { thisDoc = RhinoDoc.ActiveDoc;
initialize = (!previouslyActive) ? true : false;
RhinoDoc.LayerTableEvent -= RhinoDoc_LayerTableEvent; RhinoDoc.LayerTableEvent += RhinoDoc_LayerTableEvent; previouslyActive = true;
} else {
RhinoDoc.LayerTableEvent -= RhinoDoc_LayerTableEvent; previouslyActive = false; }
if (ev != null) { dName = ev.Document.Name; layerIndex = ev.LayerIndex; eventType = ev.EventType.ToString();
if (!exclusions.Contains("Active")) { if (ev.EventType.ToString() == "Current") { // active layer has just been changed current = true; }
}
if (!exclusions.Contains("Moved")) { if (ev.EventType.ToString() == "Sorted") { // active layer has just been changed moved = true; }
}
if (!exclusions.Contains("Added")) { if (ev.EventType.ToString() == "Added") { // layer has just been added activePath = ev.NewState.FullPath; added = true; }
}
if (!exclusions.Contains("Active")) { if (ev.EventType.ToString() == "Deleted") { // layer has just been added
deleted = true; } }
if (ev.EventType.ToString() == "Modified") { // layer has been modified activePath = ev.NewState.FullPath;
//skip sortindex eventType = ev.EventType.ToString();
if (ev.OldState != null && ev.NewState != null) { if (!exclusions.Contains("Locked")) { if (ev.OldState.IsLocked != ev.NewState.IsLocked) locked = true;
} if (!exclusions.Contains("Visibility")) { if (ev.OldState.IsVisible != ev.NewState.IsVisible) visibility = true; }
if (!exclusions.Contains("Moved")) { if (ev.OldState.ParentLayerId != ev.NewState.ParentLayerId) moved = true; }
//if (ev.OldState.SortIndex != ev.NewState.SortIndex) moved = true; if (!exclusions.Contains("Renamed")) { if (ev.OldState.Name != ev.NewState.Name) renamed = true; }
if (!exclusions.Contains("Color")) { if (ev.OldState.Color != ev.NewState.Color) color = true; } }
} }
DA.SetData(0, initialize); DA.SetData(1, dName); DA.SetData(2, activePath); DA.SetData(3, layerIndex); DA.SetData(4, sortIndex); DA.SetData(5, eventType); DA.SetData(6, added); DA.SetData(7, deleted); DA.SetData(8, moved); DA.SetData(9, renamed); DA.SetData(10, locked); DA.SetData(11, visibility); DA.SetData(12, color); DA.SetData(13, current);
}
static bool previouslyActive = false; Rhino.DocObjects.Tables.LayerTableEventArgs ev = null;
void RhinoDoc_LayerTableEvent(object sender, Rhino.DocObjects.Tables.LayerTableEventArgs e) { ev = e;this.ExpireSolution(true); }
And for the layer visibility component:
public LayerTools_SetActiveLayer() : base("Set Active Layer", "SetActiveLayer", "Set the active layer in the Rhino document.", "Squirrel", "Layer Tools") { }
/// <summary> /// Registers all the input parameters for this component. /// </summary> protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager) { pManager.AddBooleanParameter("Active", "A", "Set to true to change the active layer in Rhino.", GH_ParamAccess.item, false); pManager.AddTextParameter("Path", "P", "Full path of the layer to be activated.", GH_ParamAccess.item); }
/// <summary> /// Registers all the output parameters for this component. /// </summary> protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager) { pManager.AddIntegerParameter("Layer ID", "ID", "Index of layer that has been activated.", GH_ParamAccess.item); pManager.AddBooleanParameter("Status", "St", "True when the layer has been activated.", GH_ParamAccess.item); }
/// <summary> /// This is the method that actually does the work. /// </summary> /// <param name="DA">The DA object is used to retrieve from inputs and store in outputs.</param> protected override void SolveInstance(IGH_DataAccess DA) { bool active = false; string path = "";
if (!DA.GetData(0, ref active)) return; if (!DA.GetData(1, ref path)) return;
int layer_index = -1; bool status = false;
if (path != null) {
Rhino.RhinoDoc doc = Rhino.RhinoDoc.ActiveDoc; Rhino.DocObjects.Tables.LayerTable layertable = doc.Layers;
layer_index = layertable.FindByFullPath(path, true);
if (layer_index > 0) { // if exists RhinoDoc.ActiveDoc.Layers.SetCurrentLayerIndex(layer_index, true); status = true; } }
DA.SetData(0, layer_index); DA.SetData(1, status); }
Now originally I was getting exceptions when changing multiple layers' visibility properties, which would cause the Event Listener to fire and try to read the Visibility property before the memory has been released by the Set Layer Visibility component. That led me to add an "Exceptions" input, that would allow me to disable the reading of Visibility events at the source in the Layer Events listener. That helped me manage about 95% of the crashes I was getting, but I still get strange crashes in other event properties, even when that property shouldn't be affected. For instance, I am getting a crash here on the Name property in the event from the delegate function, even though I am only changing Visibility at any one time:
I have a few ideas but they all seem pretty hacky. One is to try to set a flag that is readable by any component in the plugin -- so that the event listener can see if a "set" component is currently running and abort before causing an exception. The other is creating a delay in the event listener, somthing like 200ms, to allow any set components to finish what they are doing before reading the event. Neither seems super ideal.
Any ideas?
Thanks,
Marc
…
t. So here we go!
1. Honeybee is brown and not yellow [stupid!]...
As you probably remember Honeybee logo was initially yellow because of my ignorance about Honeybees. With the help of our Honeybee expert, Michalina, now the color is corrected. I promised her to update everyone about this. Below are photos of her working on the honeybee logo and the results of her study.
If you think I'm exaggerating by calling her a honeybee expert you better watch this video:
Thank you Michalina for the great work! :). I corrected the colors. No yellow anymore. The only yellow arrows represent sun rays and not the honeybee!
2. Yellow or brown, W[here]TH Honeybee is?
I know. It has been a long time after I posted the initial video and it is not fun at all to wait for a long time. Here is the good news. If you are following the Facebook page you probably now that the Daylighting components are almost ready.
Couple of friends from Grasshopper community and RADIANCE community has been helping me with testing/debugging the components. I still think/hope to release the daylighting components at some point in January before Ladybug gets one year old.
There have been multiple changes. I finally feel that the current version of Honeybee is simple enough for non-expert users to start running initial studies and flexible enough for advanced users to run advanced studies. I will post a video soon and walk you through different components.
I think I still need more time to modify the energy simulation components so they are not going to be part of the next release. Unfortunately, there are so many ways to set up and run a wrong energy simulation and I really don’t want to add one new GIGO app to the world of simulation. We already have enough of that. Moreover I’m still not quite happy with the workflow. Please bear with me for few more months and then we can all celebrate!
I recently tested the idea of connecting Grasshopper to OpenStudio by using OpenStudio API successfully. If nothing else, I really want to release the EnergyPlus components so I can concentrate on Grasshopper > OpenStudio development which I personally think is the best approach.
3. What about wind analysis?
I have been asked multiple times that if Ladybug will have a component for wind study. The short answer is YES! I have been working with EFRI-PULSE project during the last year to develop a free and open source web-based CFD simulation platform for outdoor analysis.
We had a very good progress so far and our rockstar Stefan recently presented the results of the work at the American Physical Society’s 66th annual DFD meeting and the results looks pretty convincing in comparison to measured data. Here is an image from the presentation. All the credits go to Stefan Gracik and EFRI-PULSE project.
The project will go live at some point next year and after that I will release the Butterfly which will let you prepare the model for the CFD simulation and send it to EFRI-PULSE project. I haven’t tried to run the simulations locally yet but I’m considering that as a further development. Here is how the component and the logo looks like right now.
4. Teaching resources
It has been almost 11 months from the first public release of Ladybug. I know that I didn't do a good job in providing enough tutorials/teaching materials and I know that I won’t be able to put something comprehensive together soon.
Fortunately, ladybug has been flying in multiple schools during the last year. Several design, engineering and consultant firms are using it and it has been thought in several workshops. As I checked with multiple of you, almost everyone told me that they will be happy to share their teaching materials; hence I started the teaching resources page. Please share your materials on the page. They can be in any format and any language. Thanks in advance!
I hope you enjoyed/are enjoying/will enjoy the longest night of the year. Happy Yalda!
Cheers,
-Mostapha
…
diseño computacional.
La Visiting School digitalMed 2014, promovida por Medaarch y Emwesoft Sevilla S.L.N.E, se celebrará en la ciudad de Sevilla, y tendrá como tema central la Smart City y el estudio de la interacción entre las personas y su entorno a través de objetos, dispositivos e infraestructuras.
Fecha limite de inscripción: 16/01/2014
info@emwesoft.com
OBJECTIVOS Adquirir la capacidad de gestionar flujos de datos en los que las ciudades están sumergidas, para insertar proyectos que sean útiles, contextualizados, poco invasivos y aptos a establecer un intercambio de informaciones con los usuarios.
El objetivo final es redactar un catálogo de proyectos que puedan formar parte de un contexto urbano y puedan delinear el perfil de las ciudades en las que viviremos en el futuro próximo.
METODOLOGÍA Metodología basada en el aprendizaje activo, en la puesta en práctica de métodos activos que estimulan y facilitan el intercambio de experiencias y puntos de vista entre el alumnado: Buscando la participación del alumno, planteando todas las cuestiones que considere necesarias a la hora de aclarar conceptos.
Fomentando el debate y la colaboración entre los participantes.
Dando respuesta a las dudas planteadas.
La metodología será presencial, lo cual permite un mayor acercamiento entre profesor y alumno, y en consecuencia una mayor asimilación de los conceptos.
PROGRAMA Los primeros días del taller serán dedicados a establecer definiciones comunes que nos permitan trabajar a partir de significados compartidos. En esta fase se tratarán temáticas que recurren a menudo en la práctica arquitectónica contemporánea, es decir el diseño computacional, la fabricación digital y los data driven. Los alumnos tendrán la posibilidad de aprender a usar software para el diseño paramétrico, como Rhinoceros y el plug-in Grasshopper, a través del conocimiento de dichos software, el alumno conseguirá competencias teóricas y técnicas, para un enfoque al diseño computacional.
PROFESORADO La formación será impartida por profesionales con amplio conocimiento y experiencia en el ámbito. Los tutores serán los arquitectos Amleto Picerno Ceraso y Francesca Viglione.
DURACIÓN TOTAL DEL TALLER
40 horas
QUIÉN PUEDE PARTICIPAR?
. Funcionarios con una actitud proactiva hacia la construcción de ciudades inteligentes;
. Académicos y estudiantes en áreas relacionadas con el desarrollo de proyectos y soluciones tecnológicas para ciudades digitales y ciudades inteligentes;
. Arquitectos;
. Ingenieros;
. Diseñadores;
. Profesionales de las tecnologías de información y con relación a el área de tecnología.
REQUISITOS BÁSICOS
- Conocimiento básico de Rhinoceros
- Inglés medio
*Disponibilidad de un intérprete español.
PRECIO y Tarifa especial
El cuesto del taller es de 500€.
También hay facilitacióno en caso de Inscripciones de grupo: para cada grupo formado por 5 inscriptos, que paguen en un única solución, el costo total será de 4 miembros y no 5 (una persona gratis)
DONDE
Emwesoft Sevilla S.L.N.E C/ Monte Carmelo 21, 41011 – Sevilla (España)
Teléfono: +34 (955) 224 524
Email: info@emwesoft.com
Internet: www.emwesoft.com …
uce 2 curves that run across the surface =
and then with simple definition I rearrange my closest grid points to snap onto the new curves and let the rest of the points to adjust so that it has even distribution distance between points =
(notice that I don't want to have the UV to follow the curve direction. so I can get different numbers of point in-between those 2 curves). so far so good, but....
the problem comes when I try to rebuild the cell, each cell border will have this skewed look =
this problem can be solved by manually readjusting the numbers of UV grid and by sliding the grid along UV line, so I think it is time to use the galapagos, so I introduce 4 genomes pool to start with =
a) genome: numbers of Srf division in U direction (slider)
b) genome: numbers of Srf division in V direction (Slider)
c) genome: Graph Mapper to slide edges along U direction (custom GraphMapper)
d) genome: Graph Mapper to slide edges along V direction (custom GraphMapper)
I tried to then run the galapagos solver, I basically run 2 test.
the first one is by enabling all the genome except the number of UV Grid.Galapagos only allows edges to slides along the Surface, however the result is not as I expected, it is still a "skewed" grid =
and the 2nd test which enabling Galapagos to control the number of points in UV grid as well as letting the edges slide along the surface.the result is still not right =
maybe there is something wrong with the way I try to define the fitness value, just for comparison,this is the result I adjust it myself (manually dragging the sliders), it is not the best but at least the cell grid is more "tidy"=
If it is possible for you guys to give me a little insight, maybe you have a better logic to define the fitness value? I want to have 2 option for galapagos to solve =
1. rearrange the grid, however the grid should be almost square.
2. rearrange the grid, allows the grid to be either square or rectangle.
how to define this logic? because I think my current logic for fitness value does not work.
I was thinking of doing it with kangaroo but I want the grid to still follows the original surface. If I do mesh relaxation in kangaroo, the Grid would be detached from original surface and probably will have creases near the 2 curves.
thank you very much for reading this long post. I hope you can help me out :)…