In plot3d2 and similar graphic functions of Scilab, is there a way to set the colour of the back (reverse, flip, inner) side of facets?
I'm trying to draw a part of a (rather crude) torus, and the result is OK except for one row of facets. I suppose that, because of the way I generate the mesh, those facets are oriented differently - whatever algorithm renders them on the screen follows their perimeter in the opposite direction compared to others.
Instead of poring over my code to try to mend the topology of my mesh, I'd rather make sure the facet orientation doesn't matter - just set both sides to my colour. It will also improve the looks of the ends of my torus, where the inside shows and, again, is in a colour I didn't ask for.
But, hard as I search the documentation, I cannot find any mention of the flip side of mesh facets.
Any clues?
The backface color is named "hiddencolor" in the properties of a surface entity (see https://help.scilab.org/docs/6.1.1/en_US/surface_properties.html). It can be changed a posteriori, for example:
[X,Y]=meshgrid(-1:0.5:1);
plot3d2(X,Y,X.^2-2*Y.^2)
gce().hiddencolor=color("red")
You can assign -1 (instead of above) to use the same color as the front facing patches.
However, if all your patches are facing wrongly, you can also transpose all your matrices in the plot3d2 call:
[X,Y]=meshgrid(-1:0.5:1);
plot3d2(X',Y',(X.^2-2*Y.^2)')
gce().hiddencolor=color("red")
Related
I'm currently working on a glsl shader (EDIT : I'm starting to think that a shader isn't necessarily the best solution and as I'm doing this in processing, I can consider a vectorial solution too) supposed to render something like this but filling the entire 2D space (or at least a larger surface):
To do so, I want to map the repeating patterns on the general leaves shapes that you can see on the top of the sketch below.
My problem is this mapping part : is it possible to find a function that project XY coordinates on the screen to another position in such a way that I can map my patterns the way I want? The leaves must have some kind of UV coordinates inside them (to be able to apply the repeating pattern) and the transformation must be a conformal map because otherwise, there would be some distortions in the pattern.
I've tried several lines of thought but I haven't managed to get the final result :
recursion :
the idea is to first cut the plane in stripes, then cut the stripes in leaves shapes that touch the top and the bottom of the stripes (because that's easier) and finally recursively cut the leaves in halves until the result looks more random. as long as the borders of the stripe aren't on the screen, it shouldn't be too noticeable. The biggest difficulty here is to avoid the distortion.
voronoi :
it may be possible to find a distance function guided by a vector field such that the Voronoi diagram looks more like what I'm looking for. However I don't think it will be possible to have the UV mapping I want. If it's the case, a good approximation woult do the trick, the result doesn't need to be exact as long as it isn't too noticable.
distortion :
it could also be possible to find a more direct way to do this projection. While desperately looking for a solution, I came across the fact that a continuous complex function is a conform map but I haven't managed to go any further.
Finaly, there may be another solution I haven't thought about and I would be glad if someone gave me a complete solution or just a new idea I haven't tried yet.
I am playing around with rgl and I have created a 3D rendering of the mouse brain, in which structures can be isolated and coloured separately.
The original data is a 3D array containing evenly spaced voxels.
Every voxel is coded with a structure ID.
Every structure is rendered separately as a mesh by marching cubes, and smoothed using Laplacian smoothing as implemented by Rvcg.
Some of these structures can be quite small, and it would make sense to look at them within the context of the whole brain structure.
One of the options is to create a low-threshold mesh of the whole set of voxels, so that only the outer surface of the brain is included in the mesh.
This surface can be smoothed and represented using a low alpha in rgl::shade3d colouring faces. This however seems to be quite taxing for the viewport as it slows down rotation etc especially when alpha levels are quite low.
I was wondering if there is any way to implement some sort of cel shading in rgl, e.g. outlining in solid colours the alpha hull of the 2D projection to the viewport in real time.
In case my description was not clear, here's a photoshopped example of what I'd need.
Ideally I would not render the gray transparent shell, only the outline.
Cel shading example
Does anybody know how to do that without getting deep into OpenGL?
Rendering transparent surfaces is slow because OpenGL requires the triangles making them up to be sorted from back to front. The sort order changes as you rotate, so you'll be doing a lot of sorting.
I can't think of any fast way to render the outline you want. One thing that might work given that you are starting from evenly spaced voxels is to render the outside surface using front="points", back="points", size = 1. Doing this with the ?surface3d example gives this fake transparency:
If that's not transparent enough, you might be able to improve it by getting rid of lighting (lit = FALSE), plotting in a colour close to the background (color = "gray90"), or some other thing like that. Doing both of those gives this:
You may also be able to cull your data so the surface has fewer vertices.
I'd like to color faces on an triangular RGL mesh based on proximity to a vertex.
The thing is, it seems that a lot of the times that the vertices are associated with faces that are very far from the actual vertex location itself, which creates a problem when I want to color faces around one vertex; the faces end up being very far from where the barycenter actually is.
What I'm doing right now is this:
Compute the barycenter of all the faces in the mesh.
Use the FAR package to compute the closest n barycenters to the desired point. Keep those indices.
Based on the indices gathered, color those faces a certain color. The rest of the faces would be colored white.
colors=rep('white',num_faces)
colors[colored_faces]='red'
mesh$material=list(color=colors)
Then I would plot the mesh: plot3d(mesh)
The thing is, I'm getting very odd coloring right now, is there any established way to color faces that close to a certain coordinate/vertex?
This is what the mesh currently looks like, with the red as the 'colored' faces, and the blue as the points that I would like there to be a colored face near.
Mesh
Update: Seeing this, my question has now been modified to:
How can I find the closest face to a given point? It still isn't clear to me, since the face barycenters are sometimes misleading, and don't represent actual distance to a given vertex.
Update 2:
I've added example code and a file here: Files and code
Basically the code finds the nearest faces to a given vertex of the same 3d mesh with the nearest neighbor algorithm, and then we color those faces in our color vector (remembering to color the colors 4 times):
Except, when we run this algorithm, we only color one side of the shape: like so:
Odd
How can I make the coloring a bit more symmetric?
Update 3: This problem has been resolved! Please look to the unreleased version of rgl on Rforge for the newest version of rgl that allows for coloring of faces, vertices, and edges.
Update 4: Here is the new image by coloring the closest vertices (to show that the new rgl package works wonders):
Better Sink
Your code to compute the centroid is incorrect. You have
#Function for computing the barycenter/centroid of a face.
compute_face_centroid=function(vertices,face){
vertex=vertices[,face][-4,]
centroid=apply(X=vertex,MARGIN = 1,FUN = mean)
return(centroid)
}
This just removes the 4th row of the vertices array, which is the wrong way to convert homogeneous coordinates to Euclidean coordinates. You really need to divide the other rows by the 4th one. You can do this using the rgl function asEuclidean:
#Function for computing the barycenter/centroid of a face.
compute_face_centroid=function(vertices,face){
vertex <- asEuclidean(t(vertices[,face]))
apply(vertex, MARGIN = 2, FUN = mean)
}
There may also be other issues in your code, I haven't traced through everything yet.
BTW, the unreleased test version of rgl changes the way colours are handled in meshes, hopefully making that part of your code simpler. You can get it from R-forge.r-project.org if you want to try it. You can now specify colours by vertex or by face.
Edited to add:
Okay, I've taken a closer look now. I think your code was actually working. The compute_face_centroid should be corrected, but since your example always has value 1 for the final component, deleting it is okay.
The reason you got colouring different from what you expected is just that the triangles making up your mesh really vary in shape. If you plot your image as a wireframe you'll see this:
wire3d(file)
The centroids of those long thin triangles are quite far from your selected point.
I'm looking into creating a web application trough witch the user could draw an arbitrary picture on a canvas (only lines involved, no fill and no different colors) and then obtain an equation witch graphs the same picture they've drawn. Does anybody has any idea on witch approach would be the most sensible one?
I thought about simply using Bézier curves to draw and then calculate it's equation, but I wanted to know if there's any other approach which might be more appropriate.
Ok, here is the thing. Recently i decided i wanted to understand how Random map generation works. I found some papers and some arguments. The most interesting one was "Diamond Square algorithm" and "Midpoint Displacement". I still have to try to apply those to a software, but other than that, i ran into this site: http://www-cs-students.stanford.edu/~amitp/game-programming/polygon-map-generation/
As you can see, the idea is to use polygons. But i have no idea how to apply that a Tile-Based map, not even how to create those polygons using the tools i have (c++ and sdl). I am assuming there is no way to do it ( please correct me if i am wrong.) But if i am not, how does a non-tile map works, and how are these polygons generated?
This answer will not give you directly the answers you're looking for, but hopefully will get you close enough!
The Problem
I think what blocks you is how to represent the data. You're probably used to a 2D grid that simply represent the type of each tile. As you know, this is fine to handle a tile-based map, but doesn't properly allow you to model worlds where tiles are of a different shape.
Graphs
What I suggest to you, is to see the problem a bit differently. A grid is nothing more than a graph (more info) with nodes that have 4 (or 8 if you allow diagonals) implicit neighbor nodes. So first, what I would do if I was you, would be to move from your strict standard 2D grid to a more "loose" graph, where each node has a position, a position, a list of neighbors (in most cases you'll have corners with 2 neighbors, borders with 3 and "middle" tiles with 4) and finally a rendering component which simply draws your tile on screen at the given position. Once this is done, you should be able to have the exact same results on screen that you currently have with your "2D Tile-Based" engine by simply calling the rendering component with each node who's bounding box (didn't touch it in what you should add to your node, but I'll get back to this later) intersects with the camera's frustum (in a 2D world, it would most likely if the position +/- the size intersects the RECT currently being drawn).
Search
The more generic approach will also help you doing stuff like pathfinding with generic algorithms that explore nodes until they find a valid path (see A* or Dijkstra). Even if you decided to stick to a good old 2D Tile Map game, these techniques would still be useful!
Yeah but I want Polygons
I hear you! So, if you want polygons, basically all you need to do, is add to your nodes a list of vertices and the appropriate data that you might need to render your polygons (either vertex color, textures and U/V maps, etc...) and update your rendering component to do the appropriate OpenGL (this for example should help) calls to draw your nodes. Once again, the first step to iteratively upgrade your 2D Tile Engine to a polygon map engine would be to, for each tile in your map, give each of your nodes two triangles, a texture resource (the tile), and U/V mappings (0,0 - 0,1 - 1,0 and 1,1). Once again, when this step is done, you should have a "generic" polygon based tile map engine. The creation of most of this data can be created procedurally by calculating coordinates based on tile position, tile size, etc...
Convex Polygons
If you decide that you ever might need NPCs to navigate on your map or want to allow your player to navigate by clicking the map, I would suggest that you always use convex polygons (the triangle being the simplest for of a convex polygon). This allows your code that assume that two different positions on the same polygon can be navigated to in straight line.
Complex Maps
Based on the link you provided, you want to have rather complex maps. In this case, the author used Voronoi Diagrams to generate the polygons of the map. There are already solutions to do triangulation like that, but you might also want to use other techniques that are easier to work with if you're just switching to 3D like this one for example. Once you have interesting results, you should consider implementing serialization to save/open your map data from the game. If you want to create an editor, be aware that it might be a lot of work but can be worth it if you want people to help you creating maps or to add elements to the maps (like geometry that's not part of the terrain).
I went all over the place with this answer, but hopefully it helps!
Just iterate over all the tiles, and do a hit-test from the centre of the tile to the polys. Turn the type of the tile into the type of the polygon. Did you need more than that?
EDIT: Sorry, I realize that probably isn't helpful. Playing with procedural algorithms can be fun and profitable. Start with a loop that iterates over all tiles and chooses randomly whether or not the tile is occupied. Then, iterate over them again and choose whether it is occupied or its neighbour is.
Also, check out the source code for this: http://dustinfreeman.org/toys/wall7-dustin.html