I understand about the power of layers for additive operations, ie extending a diagram by showing more options/more detail etc.
However what I want to understand is what is the way in which layers can be used to fundamentally change the objects in the base diagram.
for instance, if I want a business process whereby the connections between entities no long go from A to B to C but go from A to D to E, I want to be able to remove the connectors from the base layer within my FMO layer and add the new connectors acordingly.
Is there a clever way of achieving this using layers and lucidchart?
You can achieve that by having 3 layers: one for the elements that don't change (your "base layer"), one for the connectors (or elements) that you want to hide and finally one layer for the new elements. You can create a button with actions to toggle the second and third layers so that they are not visible at the same time and easily see your model evolution.
Related
I am using deck.gl to create a map by consuming data from a tile server in MVT format and I am bit stuck. I really need some help from someone with more experience.
Currently I have 10 layers but each layer generate 3 different sub layers because there are multiple shapes in the data and also I am representing some objects using Icons.
The problem is that occasionally, while interacting with the map, some objects from the map cannot be selected anymore.
They are visible but they cannot be interacted with.
The only thing that I can observe in the console is a Warning which says Too many pickable layers, only picking the first 255.
Another thing that it's worthy to mention is that all the layers have the pickable property set to true because all the objects displayed on the map needs to be
selectable.
I tried to debug this problem furthermore and I observed that internally deck.gl creates around 300-500 layer objects based on the layers structure and on the tiles received
from the tile server. From those layers around a half are marked as ready to be "garbage collected".
I am using deck.gl 8.5.7 and mapbox-gl 1.13.0.
Is there any way to force the garbage collector to remove those layers or any other fix for this problem.
Thanks in advance for your help.
I am looking to utilize Autodesk Fusion 360 to generate a huge number of shapes (tens of thousands) in 3D model form, so I need a way to operate it non-interactively.
I am aware of the Fusion 360 API documentation here https://autodeskfusion360.github.io/
But I was wondering if there is a known way to do this.
Essentially there are four main steps to create:
Create base shape (i.e. sphere, cube, trapezoid etc..) and save
Define and name each dimension on the shape as either dependent on another (ex: height/2) or an input (ex: height) until your model is fully constrained and controlled by parameters
Create a program (python is friendly) that inputs values to named inputs
Connect to a database within the program (using odbc or similar) that will iterate through shape characteristics
Input necessary characteristics from database and save unique shape within your program
You will have to be more specific in the question to clarify the answer. Please include as detailed an example as you can and I'll edit my answer.
I mean, the basics..
1) I have seen in the Online videos, that they are modelling a character (or anything) through one object only, they are extruding, loop cut, scaling, etc and model a character, why don't they design different objects separately (like hands separately, legs separately, body separate and then join them together and make one object)..??????
2) Like What the texturing department has to see so that they should not return the model back to the modelling department. I mean like the meshes(polygons) over the model face must be quad, etc not triangle. while modelling a character..
what type of basics i should know , means is there any check list or is there any basics which i should see before modelling a character..
Please correct me if i am wrong , and answer my both questions.. Thanks
It may be common but it definitely isn't mandatory to have a model as one solid mesh. Some models will have parts of the body underneath clothing removed to reduce the poly count. How the model is to be used will be a big factor to how you model it, that is a for a single image it is easy to get away with multiple parts, while a character that will be animated in a cartoony animation could be stretched and distorted in ways that could show holes in a model with multiple pieces. When working in a team, there may be rules in place determining whether a solid or multi-part model is considered acceptable.
An example of an animated model made from multiple parts is Sintel, the main character in the Sintel short animation.
There is nothing stopping you from making a library of separate body parts and joining them together when you make your model. Be aware that this can bring complications, if you model an arm with 12 verts and then you make your hand with 15, then you have to fiddle around to merge them together.
You will also find some extra freedom to work with multiple body parts during the sculpting phase as you are creating a high density mesh that is used as a template to model a clean mesh over. This step is called retopology.
It is more likely that the rigging department will send a model back for fixing than the texturing department. When adding a rig and deforming the mesh in different ways, any parts that deform badly will be revealed and need fixing.
[...] (like hands separately, legs separately, body separate and then
join them together and make one object) [...]
Some modelers I know do precisely this and they do it in a way where they block in the design using broad primitive shapes, start slicing some edge loops and add broad details, then merge everything together, then sculpt it a bit further with high-res sculpting tools, and finally retopologize everything.
The main modelers I know who do this, however, model in a way that tries to adhere as close as possible to the concept artist's illustration. They're not creating their own models from scratch but are instead given top/front/back/side illustrations of a character, for example, and are just trying to match it as closely as possible.
When you start modeling everything in small pieces, it helps to have that concept illustration since you can get lost in the topology otherwise and fusing organic meshes together can be difficult to do in a clean way.
[...] why don't they design different objects separately? [...]
Again they sometimes do, but one of the appeals of creating organic meshes by keeping it seamless the entire time is that you can start to focus on how edge loops propagate across the entire model. It helps to know that the base of a finger is a hexagon, for example, in figuring out how to cleanly propagate and terminate the edge loops for a hand, and likewise have a strategy for the hand to cleanly propagate and terminate edge loops as it joins into the forearm.
It can be hard to get the topology to match up cleanly if you designed everything in small pieces and then had to figure out how to merge it all together. Polygonal modeling is very topology-oriented. It tends to require as much thinking about the wireframe and edge flows as it does the shape of the model, since it needs to be a certain way for everything to subdivide cleanly and smoothly and animate predictably with subdivision surfaces.
I used to work with developers who took one glance at the topology-dominated workflow of polygonal modeling and immediately wanted to jump to seeking alternatives, like voxel sculpting. With voxels you could be able to potentially model everything in pieces and foose it all together in a nice and smooth organic way without thinking about topology whatsoever.
However, that loses sight of the key appeal of polygonal meshes. Their wire flow forms a control lattice with a very finite number of control points for the artist to animate and move around to predictably control the shape of their model. You immediately lose that with a voxel representation -- so while voxels free the artist of thinking about how the topology works and how the wireframe flows through the model, it also loses all those control benefits of having that. So often if people use voxel sculpting, they end up meticulously retopologizing everything at the end anyway to gain back that level of coarse and predictable control they have with polygonal meshes.
I mean like the
meshes(polygons) over the model face must be quad, etc not triangle.
while modelling a character..
This is all in the context of subdivision surfaces: the most popular of which are variants of catmull-clark. That favors quads to get the most predictable subdivision. It's much easier for the artist to predict how everything will look like and deform if they favor, as much as possible, uniform grids of quadrangles wrapped around their model with 4-valence vertices and every polygon having 4 points. Then only in the case where they kind of need to "join" these quad grids together, they might create some funky topology: a 5-valence vertex here, a 3-valence vertex there, a 5-sided polygon here, a triangle there -- but those cases tend to deform a bit unpredictably (at least unintuitively), so artists tend to try to avoid these as much as possible.
Because when artists model polygonal meshes in this way, they are not just trying to create a statue with a nice shape. If that's all they wanted to do, they'd save themselves a lot of grief avoiding dealing with things in terms of individual vertices/edges/polygons in the first place and using something like Sculptris. Instead they are designing not only shapes but also designing a control lattice, a wire flow and a set of control points they can easily move around in the future to get predictable behavior out of their control cage. They're basically designing controls or an "interactive GUI/rig" almost for themselves with how they design the topology.
2) Like What the texturing department has to see so that they should
not return the model back to the modelling department.
Generally how a mesh is modeled in a direct sense shouldn't affect the texture department's work much at all if they're working with UV maps and painting textures over them (at that point it doesn't really matter if a model has clean wire flows or not, since all the texture artists do is pain images over the 2D UV map or directly onto the 3D model).
However, if the modeler does the UV mapping, then regardless of whether he uses quad meshes and clean wire flows or not, if the UV mapping is poor, then the resulting texture images will look all distorted. So the UV maps need to be made well with minimal distortion, though that's usually easy to do automatically these days.
The other exception is if the department doesn't use UV maps and instead uses, say, PTex from Disney. PTex really favors quads. In the original paper at least, it only worked with quads.
I'm a bit confused in which situations these patterns should be used, because in some sense, they seem similar to me?
I understand that Layered is used when system is complex, and can be divided by its hierarchy, so each layer has a function on different level of hierarchy, and uses the functions on the lower level, while in the same time exposes its function to higher level.
On the other hand, Pipe-and-Filter is based on independent components that process data, and can be connected by pipes so they make a whole that executes the complete algorithm.
But if the hierarchy does not exist, it all comes to question if order of the modules can be changed?
And an example that confuses me is compiler. It is an example of pipe-and-filter architecture, but the order of some modules is relevant, if I'm not wrong?
Some example to clarify things would be nice, to remove my confusion. Thanks in advance...
Maybe it is too late to answer but I will try anyway.
The main difference between the two architectural styles are the flow of data.
On one hand, for Pipe-and-Filter, the data are pushed from the first filter to the last one.
And they WILL be pushed, otherwise, the process will not be deem success.
For example, in car manufacturing factory, each station is placed after one another.
The car will be assembled from the first station to the last.
If nothing goes wrong, you will get a complete car at the end.
And this is also true for compiler example. You get the binary code after from the last compiling process.
On the other hand, Layered architecture dictates that the components are grouped in so-called layers.
Typically, the client (the user or component that accesses the system) can access the system only from the top-most layer. He also does not care how many layers the system has. He cares only about the outcome from the layer that he is accessing (which is the top-most one).
This is not the same as Pipe-and-Filter where the output comes from the last filter.
Also, as you said, the components in the same layer are using "services" from the lower layers.
However, not all services from the lower layer must be accessed.
Nor that the upper layer must access the lower layer at all.
As long as the client gets what he wants, the system is said to work.
Like TCP/IP architecture, the user is using a web browser from application layer without any knowledge how the web browser or any underlying protocols work.
To your question, the "hierarchy" in layered architecture is just a logical model.
You can just say they are packages or some groups of components accessing each other in chain.
The key point here is that the results must be returned in chain from the last component back to the first one (where the client is accessing) too.
(In contrast to Pipe-and-Filter where the client gets the result from the last component.)
1.) Layered Architecture is hierarchical architecture, it views the entire system as -
hierarchy of structures
The software system is decomposed into logical modules at different levels of hierarchy.
where as
2.) Pipe and Filter is a Data-Flow architecture, it views the entire system as -
series of transformations on successive sets of data
where data and operations on it are independent of each other.
In an n-layered (5-layer, let's say) application, if there are options available for a certain operation to bypass one of the layers and communicate with the next layer directly, can it still be called an "n-layer" architecture, or does it turn into an (n-1)-layered (4-layer) architecture?
And should the layer in question, which you can bypass, be considered as a "layer" at all?
EDIT: I'm trying to implement an application with following structure -
Presentation layer (contains WPF grids)
Application layer (contains application logic and workflow as application services, extracts display model objects from domain model objects, which are then bound to the UI grids)
Domain layer (contains domain model objects only)
Repository (stores data fetched from the database, isolates the lower layers from the upper layer)
Data mapping layer (maps domain model objects to data model objects)
Data access layer (contains data model objects, and stores and retrieves data to and from the database)
-each one above is implemented as separate project and the domain layer is referenced by the application layer, repository and data mapping layer. Now the thing is, the application layer is directly communicating with the repository, not through the domain layer and the domain layer (if I can call it a layer at all) is acting just like a cross-cutting reference. So that's where my question comes, should I call it domain "layer"? I think NOT. But in domain-driven Design there exists a domain layer, right? There must be something wrong in my architecture? Where and what is it?
You could have as many layers as you want and call it an n-layered system...whether they are used properly or loosely coupled is another question.
The fact that you talk about bypassing a layer may mean you've over engineered a solution or you have implemented a layer in an unhelpful/incorrect way...You'd need to be providing some samples of usage to really help out more here...