I'm trying to texture a scene on Autodesk 3ds max, what I'm doing:
Select an object and add Unwrap UVW modifier
Select all faces and Open UV Editor
Flatten Mapping and Render UVW Template
Save the template as .jpeg and open it on Photoshop
Add the texture/images and save it as .psd
I add the .psd file on the map editor and on UV editor
The problem is that in the rendered image I get green lines on the edges for some reason.
UV Template:
Is there any way to fix it?
Thanks in advance
From what I can tall, you have the green lines because those mark the edges of the template, but they aren't supposed to be included in the final template. Since you're using Photoshop, you could use magic wand to select the faces and then expand each selection by a pixel on each side (assuming the green lines are each one pixel wide) and delete, then drop in your face textures (making sure the textures are the right size for the regions you're placing them in, of course)).
A more accurate method, as JPEG files can have artifacts that make region selection tricky sometimes, would be to use multiple layers in your PSD file and place the textured faces exactly on top of the green-outlined regions in different layers, then merge all the layers together (unless 3DS Max supports multilayer PSDs, in which case you wouldn't need to do that unless you wanted to save space, in which case you'd want to export as a more compact image type anyway).
A third method would be to use textures for each face that are slightly larger than the bounds and just place them approximately over the face positions to cover up the green; this would avoid having to be exact, but it would also mean that you'd end up with discontinuities on the edges as adjacent textures would not perfectly match each other.
Related
So I have created a 2D animation that consists of 3D Perlin noise where the X & Y axes are the pixel positions on the matrix/screen and the Z axis just counts up over time. I then apply a threshold so it only shows solid shapes unlike the cloud type pattern of the normal noise. In effect it creates a forever moving fluid animation like so https://i.imgur.com/J9AqY5s.gifv
I have been trying to think of a way I can track and maybe index the different shapes so I can have them all be different colours. I'm tried looping over the image and flood filling each shape but this only works for one frame as it doesn't track which shape is which and how they grow and shrink.
I think there must be a way to do something like this because if I had a colouring pencil and each frame on a piece of paper I would be able to colour and track each blob and combine colours when two blobs join. I just can't figure out how to do this programmatically. The nature in which Perlin-noise works and since the shapes aren't defined objects I find it difficult to wrap my head around how I would index them.
Hopefully, my explanation has been sufficient, any suggestions or help would be greatly appreciated.
Your current algorithm effectively marks every pixel in a frame as part of a blob or part of the background. Let's say you have a second frame buffer that can hold a color for every pixel location. As you noted, you can use flood fill on the blob/background buffer to find all the pixels that belong to a blob.
For the first frame, assign colors to each blob you find and save them in the color buffer.
For the second (and each subsequent) frame, you can again use flood fill on the blob/background buffer to determine all the pixels that belong to a discrete blob. Look up the colors corresponding to those each of those pixels from the color buffer (which represents the colors from the last frame) and build a histogram of all the colors you find.
The histogram will contain some of the pixels of the background color (because the blob may have moved or grown into an area that was background).
But since the blobs move smoothly, many of the pixels that are part of a given blob this frame will have been be part of the same blob on the last frame. So if your histogram has just one non-background color, that's the color you would use.
If the histogram contains only the background color, this is a new blob and you can assign it a new color.
If the histogram contains two (or more) blob colors, then two (or more) blobs have merged, and you can blend their colors (perhaps in proportion to their histogram counts with correspond to their areas).
This trick will be to do all this efficiently. The algorithm I've outlined here gives the idea. An actual implementation may not literally build histograms and might take recalculate each pixel color frame scratch on every frame.
I am actually trying to develop a web application that would visualize a Finite Element mesh. In order to do so, I am using WebGl. Right now I have a page with all the code necessary to draw the mesh in the viewport using triangles as primitives (each quad element of the mesh was splitted into two triangles to draw it). The problem is that, when using triangles, all the piece is "continuous" and you cant see the separation between triangles. In fact, what I would like to achieve is to add lines between the nodes so that, around each quad element (formed by two triangles) we have these lines in black, and so the mesh can actually be shown.
So I was able to define the lines in my page, but since one shader just can have one type of primitive, if I add the code for the line buffers and bind them it just show the lines, not the element (as they were the last buffers binded).
So the closest solution I have found is using multiple shaders, and managing them with multiple programs, but this solution would just enable me whether to plot the geometry with trias or to draw just the lines, depending on which program is currently selected.
Could any of you help me about how to approach this issue? I have seen a windows application that shows FE meshes using OpenGL and it is able to mix the triangles with points and lines, apart from using different layers, illumination etc. So I am aware that this may be complicated, but I assume that if it is possible somehow with OpenGl it should be as well with webGL.
Please if you provide any solution I would appreciate a lot that it contains some code as an example, for instance drawing a single triangle but including three black lines at its borders and maybe three points at the vertices.
setup()
{
<your current code here>
Additional step - Unbind the previous textures, upload and bind one 1x1 black pixel as a texture. Let this texture object be borderID;
}
Draw loop()
{
Unbind the previous textures, bind your normal textures, and draw the mesh like your current setup. This will fill the entire area with different colours, without border (the current case)
Bind the borderID texture, and draw the same vertices again except this time, use context.LINE_STRIP instead of context.TRIANGLES. This will draw lines with the black texture, and will appear as border, on top of the previously drawn colors for each triangle. You can have something like below
if(currDrawMode==0)
context3dStore.bindTexture(context3dStore.TEXTURE_2D, meshTextureObj[bindId]); else context3dStore.bindTexture(context3dStore.TEXTURE_2D, borderTexture1pixObj[bindId]);
context3dStore.drawElements((currDrawMode == 0) ? context3dStore.TRIANGLES: context3dStore.LINE_LOOP, indicesCount[bindId], context3dStore.UNSIGNED_SHORT, 0); , where currDrawMode toggles between drawing the border and drawing the meshfill.
Since the line texture appears as a border over the flat colors you had earlier, this should solve your need
}
I got a png image like this:
The blue color is represent transparent. And all the circle is a pixel group. So, I would like to find the biggest one, and remove all the small pixel, which is not group with the biggest one. In this example, the biggest one is red colour circle, and I will retain it. But the green and yellow are to small, so I will remove them. After that, I will have something like this:
Any ideas? Thanks.
If you consider only the size of objects, use the following algorithm: labellize the connex components of the mask image of the objects (all object pixels are white, transparent ones are black). Then compute the areas of the connex components, and filter them. At this step, you have a label map and a list of authorized labels. You can read the label map and overwrite the mask image with setting every pixel to white if it has an authorized label.
OpenCV does not seem to have a labelling function, but cvFloodFill can do the same thing with several calls: for each unlabeled white pixel, call FloodFill with this pixel as marker. Then you can store the result of this step in an array (of the size of the image) by assigning each newly assigned pixel with its label. Repeat this as long as you have unlabellized pixels.
Else you can recode the connex component function for binary images, this algorithm is well known and easy to implement (maybe start with Matlab's bwlabel).
The handiest way to filter objects if you have an a priori knowledge of their size is to use morphological operators. In your case, with opencv, once you've loaded your image (OpenCV supports PNG), you have to do an "openning", that is an erosion followed by a dilation.
The small objects (smaller than the size of the structuring element you chose) will disappear with erosion, while the bigger will remain and be restored with the dilation.
(reference here, cv::morphologyEx).
The shape of the big object might be altered. If you're only doing detection, it is harmless, but if you want your object to avoid transformation you'll need to apply a "top hat" transform.
I was making a circular icon with semi-transparency, so I started with a large filled-in circle with a black border, then I did white->alpha, and resized the image to my required size. Would it have made a difference if I resized first, and then did white->alpha?
Thanks.
Yes.
In general, whenever you are re-sampling, this will have an impact if you are using any anti-aliasing, or the resampling algorithm is something other than nearest-neighbor.
Try the following exercise for a visual example:
In both cases, create your circular icon.
Case 1:
Change white-center of the circle to alpha (0%, fully transparent).
Re-sample (ie: down-sample to 25%) the entire image using something other than nearest neighbour (ie: actually use antialiasing of some sort)
Paste a copy of the result over a red background.
You should only see black and red colors inside the circle when you zoom in, with a smooth transition from black-to-red.
Case 2:
Re-sample (ie: down-sample to 25%) the entire image using something other than nearest neighbour (ie: actually use antialiasing of some sort)
Change white-center of the circle to alpha (0%, fully transparent).
Paste a copy of the result over a red background.
You should see a black outer circle, with a bit of a white halo inside of it, then the red center, with a smooth black-to-white transition, and a sharp white-to-red transition. This will depend on the aggressiveness factor you set with the magic-wand tool you are likely using to auto-select the region you want to modify the alpha properties of.
Now repeat case 2, but disable any sort of anti-aliasing, and enforce the use of a nearest neighbour algorithm rather than bi-cubic spline, Hermite, Gaussian, etc. Your results will look very similar to case 1, except you won't see the smooth transition from black-to-red when you zoom in, you will just see a sharp black-to-red transition.
In general, you will get the best subjective quality when working on your images first, then re-sampling later. If you paste it as its own layer, then you still have all the image data available any none is lost, the image is just rendered smaller.
I come from a 2D animation background and so when ever I us an animated sequence I prefer to use a sequence of images. To me this makes a lot of sense because you can easily export the image sequence from your compositing/editing software and easily define the aspect.
I am new to game development and am curious about the use of a sprite sheet. What are the advantages and disadvantages. Is file size an issue? - to me it would seem that a bunch of small images would be the same as one massive one. Also, defining each individual area of the sprites seems time cumbersome.
Basically, I dont get why you would use a sprite sheet - please enlighten me.
Thanks
Performance is better for sprite sheets because you have all your data contained in a single texture. Lets say you have 1000 sprites playing the same animation from a sprite sheet. The process for drawing would go something like.
Set the sprite sheet texture.
Adjust UV's to show single frame of animation.
Draw sprite 0
Adjust UV's
Draw sprite 1
.
.
.
Adjust UV's
Draw sprite 998
Adjust UV's
Draw sprite 999
Using a texture sequence could result in a worst case of:
Set the animation texture.
Draw sprite 0
Set the new animation texture.
Draw sprite 1
.
.
.
Set the new animation texture.
Draw sprite 998
Set the new animation texture.
Draw sprite 999
Gah! Before drawing every sprite you would have to set the render state to use a different texture and this is much slower than adjusting a couple of UV's.
Many (most?) graphics cards require power-of-two, square dimensions for images. So for example 128x128, 512x512, etc. Many/most sprites, however, are not such dimensions. You then have two options:
Round the sprite image up to the nearest power-of-two square. A 16x32 sprite becomes twice as large with transparent pixel padding to 32x32. (this is very wasteful)
Pack multiple sprites into one image. Rather than padding with transparency, why not pad with other images? Pack in those images as efficiently as possible! Then just render segments of the image, which is totally valid.
Obviously the second choice is much better, with less wasted space. So if you must pack several sprites into one image, why not pack them all in the form of a sprite sheet?
So to summarize, image files when loaded into the graphics card must be power-of-two and square. However, the program can choose to render an arbitrary rectangle of that texture to the screen; it doesn't have to be power-of-two or square. So, pack the texture with multiple images to make the most efficient use of texture space.
Sprite sheets tend to be smaller
files (since there's only 1 header
for the whole lot.)
Sprite sheets load quicker as there's
just one disk access rather than
several
You can easily view or adjust multiple frames
at once
Less wasted video memory when you
load the whole lot into one surface
(as Ricket has said)
Individual sprites can be delineated by offsets (eg. on an implicit grid - no need to explicitly mark or note each sprite's position)
There isn't a massive benefit for using sprite sheets, but several small ones. But the practice dates back to a time before most people were using proper 2D graphics software to make game graphics so the artist workflow wasn't necessarily the most important thing back then.