I have a question and hope you can help me with it. I've been busy making a game with xna and have recently started getting into shaders (hlsl). There's this shader that i like, use, and would like to improve.
The shader creates an outline by drawing the back faces of a model (in black), and translating the vertex along its normal. Now, for a smooth-shaded model, this is fine. I, however, am using flat-shaded models (I'm posting this from my phone, but if anyone is confused about what that means, I can upload a picture later). This means that the vertices are translated along the normal of its corresponding face, resulting in visible gaps between the faces.
Now, the question is: is there a way to calculate (either in the shader or in xna), how i should translate each vertex, or is the only viable option just making a copy of the 3d model, but with smooth shading?
Thanks in advance, hope you can educate me!
EDIT: Alternatively, I could load only a smooth-shaded model, and try to flat-shade it in the shader. That would, however, mean that I have to be able to find the normals of all vertices of the corresponding face, add their normals, and normalize the result. Is there a way to do this?
EDIT2: So far, I've found a few options that don't seem to work in the end: setting "shademode" in hlsl is now deprecated. Setting the fillmode to "wireframe" would be neat (while culling front faces), if only I would be able to set the line thickness.
I'm working on a new idea here. I could maybe iterate through vertices, find their position on the screen, and draw 2d lines between those points using something like the RoundLine library. I'm going to try this, and see if it works.
Ok, I've been working on this problem for a while and found something that works quite nicely.
Instead doing a lot of complex mathematics to draw 2d lines at the right depth, I simply did the following:
Set a rasterizer state that culls front faces, draws in wireframe, and has a slightly negative depth bias.
Now draw the model in all black (I modified my shader for this)
Set a rasterizer state that culls back faces, draws in fillmode.solid and has a 0 depth bias.
Now draw the model normally.
Since we can't change the thickness of wireframe lines, we're left with a very slim outline. For my purposes, this was actually not too bad.
I hope this information is useful to somebody later on.
Related
I am trying to make my first steps with the vulkan raytracing extension from nvidia.
More precisely, I try to trace a simple triangle as a first step to get things going. However, as I expect my code to render a triangle like I want to, somehow a cube is traced and I can't find my mistake.
I think it must have something to do with the creation of my acceleration structures, as the cube gets bigger , when I move the vertices around. Maybe I'm only tracing the top level acceleration structure (maybe the cube is the bounding volume of the triangle?) and ignore the content of the bottom level acceleration structure completely, but I'm not sure about that.
I oriented myself on the vulkan "raytracing basic" example of Sascha Willems. (https://github.com/SaschaWillems/Vulkan/blob/master/examples/nv_ray_tracing_basic/nv_ray_tracing_basic.cpp)
In other words, I tried to recreate his code in my own framework.
Therefore, my Expectation to see was the same as the output of his example:
But my own code produces the discussed cube as follows:
Cube front:
Cube after slight rotation:
The red color comes from the closest hit shader. The plan is to take the "in" value for the shader and interpret it as barycentric coordinates to create the desired shading.
In case of my own code, the value is always the same, as it will produce the same red color each time it is evaluated.
Does anybody have an idea about such a problem?
My source code can be found on github, if someone is interested: https://github.com/mharrer97/saiga/blob/master/src/saiga/vulkan/raytracing/Raytracer.cpp
EDIT: I've solved the issue below the tilde line -- the missing chunks -- by fixing an elementary error in my for-loop dealing with calculating face normals. I now have a new problem though: strange, unwanted shadows on the surface itself. Some areas appear darker than others... See the next picture for the current issue.
I have an omni light added to my scene's root node as well as a directional light added in the same manner. For some reason I can't seem to light the underbelly of the surface otherwise. Notice the strange shadow on the inside of the concave surface (it's more pronounced when I remove the subdivision effect as I have done here) -->
Here is the surface from above -- notice how some areas seem strangely darker.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is a concave surface.
I have these smooth, curved planes in 3D space. Right now, they look rather cartoonish -- I would like to utilize some form of lighting to make them look more "3D-ish."
I have tried various combinations of ambient lighting, omni lighting, and default lighting, but nothing seems to work right. I get something quite strange when I apply something like a basic omni light --
Here is another look at a better angle using omni lighting. Looks like someone took a bite out of it --
Am I overlooking a specific type of light or lighting strategy?
I'd like to avoid used baked lighting, because the scene is rather simple. Thanks.
I'll outline my steps for the bold.
1: I specify the vertices for each of the four faces of a pyramid-like shape. Like this (apologies for my lack of artistic ability) -->
2: I specify the indices for the face, i.e., [0,1,2, 0,2,3, etc.]
I create a dictionary mapping each vertex to the sum of that vertex's adjacent, normalized face normals.
I append each of these summed up normalized per-vertex normals to a vector.
I combine the vertices, indices, and vector of normals to create an SCN Geometry.
To get the rounded look, I increase the subdivision count.
Pray that it works.
I'm new to the 3D world, so I could be way out in left field and not even know it.
This should give you a reasonable result with minimal effort and the least possible need to understand 3D lighting.
Open the Fox game example/sample from Apple:
https://developer.apple.com/library/prerelease/ios/samplecode/Fox/Introduction/Intro.html
Delete everything from the level.scn Scene Graph other than Lights, Camera and the Mountain.
And then add your geometry object to a node at the bottom, where I have the sphere highlighted at the bottom of the Scene Graph....
Now the material needs a bit of work, to make it useful.
Select the Mountain by clicking on it in the View, and goto the material editor and make it look like this, just keep checking against this image until yours matches the few (weird) changes I've made. And trust me this will work out fine:
When you want to get that lovely red you have, you simply change this property: DIFFUSE : It's right at the top of the Material settings.
Now you have a material and lighting setup that gives a reasonable approximation of curvature in a 3D space.
Applying this material to your object is a little weird, and unintuitive, you go here, and click on the add button, and pick the material with the same name as the one in the above image, that’s on the mountain.
You can improve this by adding two more lights in what’s known as a “3 point lighting setup”, google this phrase to see it explained.
Further, you can add off screen (out of camera) placards, usually white, to manage key reflections to further assist in users getting a feel for what’s being presented.
My question maybe a bit too broad but i am going for the concept. How can i create surface as they did in "Cham Cham" app
https://itunes.apple.com/il/app/cham-cham/id760567889?mt=8.
I got most of the stuff done in the app but the surface change with user touch is quite different. You can change its altitude and it grows and shrinks. How this can be done using sprite kit what is the concept behind that can anyone there explain it a bit.
Thanks
Here comes the answer from Cham Cham developers :)
Let me split the explanation into different parts:
Note: As the project started quite a while ago, it is implemented using pure OpenGL. The SpiteKit implementation might differ, but you just need to map the idea over to it.
Defining the ground
The ground is represented by a set of points, which are interpolated over using Hermite Spline. Basically, the game uses a bunch of points defining the surface, and a set of points between each control one, like the below:
The red dots are control points, and eveyrthing in between is computed used the metioned Hermite interpolation. The green points in the middle have nothing to do with it, but make the whole thing look like boobs :)
You can choose an arbitrary amount of steps to make your boobs look as smooth as possible, but this is more to do with performance.
Controlling the shape
All you need to do is to allow the user to move the control points (or some of them, like in Cham Cham; you can define which range every point could move in etc). Recomputing the interpolated values will yield you an changed shape, which remains smooth at all times (given you have picked enough intermediate points).
Texturing the thing
Again, it is up to you how would you apply the texture. In Cham Cham, we use one big texture to hold the background image and recompute the texture coordinates at every shape change. You could try a more sophisticated algorithm, like squeezing the texture or whatever you found appropriate.
As for the surface texture (the one that covers the ground – grass, ice, sand etc) – you can just use the thing called Triangle Strips, with "bottom" vertices sitting at every interpolated point of the surface and "top" vertices raised over (by offsetting them against "bottom" ones in the direction of the normal to that point).
Rendering it
The easiest way is to utilize some tesselation library, like libtess. What it will do it covert you boundary line (composed of interpolated points) into a set of triangles. It will preserve texture coordinates, so that you can just feed these triangles to the renderer.
SpriteKit note
Unfortunately, I am not really familiar with SpriteKit engine, so cannot guarantee you will be able to copy the idea over one-to-one, but please feel free to comment on the challenging aspects of the implementation and I will try to help.
There is very little contrast in my model.
The model frankly looks like one big blob, despite its having a complex shape. I can really only see its silhouette shape. The only details that I can see inside of the shape are created by the spot light, which is always very faint no matter how I tweak it.
What is the key to getting the shape of an object to appear clearly and to get some contrast?
Did you create normals for your triangles and pass those in? You never mentioned those, and surface normals are required before directional lighting works (A normal is a ray that is perpendicular to each surface, usually from the center of the surface.
I don't have my OpenGL references handy, but I remember the 3 kinds of lighting as directional, ambient, and specular, where ambient is global, and directional and diffuse depend on the lighting direction and the surface normals.
I would suggest starting with 1 light source first and figuring that out, then adding more lights once you get your single light working correctly.
The problem was, although I was creating normals and providing them with glNormalArray, I had not enabled GL_NORMALIZE so they weren't being used. I had been under the impression that GL_NORMALIZE automatically created normals, which is the opposite of what I wanted.
I am currently working on a 2D "Worms" clone in XNA, and one of the features is "deformable" terrain (e.g. when a rocket hits the terrain, there is an explosion and a chunk of the terrain disappears).
How I am currently doing this is by using a texture that has a progressively higher Red value as it approaches the center. I cycle through every pixel of that "Deform" texture, and if the current pixel overlaps a terrain pixel and has a high enough red value, I modify the color array representing the terrain to transparent. If the current pixel does NOT have a high enough Red value, I blacken the terrain color (it gets blacker the closer the Red value is to the threshold). At the end of this operation I use SetData to update my terrain texture.
I realize this is not a good way to do it, not only because I have read about pipeline stalls and such, but also because it can become quite laggy if lots of craters are being added at the same time. I want to remake my Crater Generation on the GPU instead using Render Targets "ping-ponging" between being the target and the texture to modify. That isn't the problem, I know how to do that. the problem is I don't know how to keep my burn effect using this method.
Here's how the burn effect looks right now:
Does anybody have an idea how I would create a similar burn effect (darkening the edges around the formed crater)? I am completely unfamiliar with Shaders but if it requires it I would be really thankful if someone walked me through on how to do it. If there are any other ways that'd be great too.
Sounds like you're good in the right way. But you're doing a lot of things by hand, which can also be done by just drawing sprites and applying the right formulas.
For example:
Suppose your terrain is saved into a giant texture in the alpha channel of the texture. 1 is terrain, 0 is nothing.
An explosion happens and the terrain has to be deformed. Update your texture easily by just drawing a black transparent sphere (or explosion area) onto your texture. The terrain is gone, because the alpha value is 0 of the black sphere. Your texture is now up to date, everything was done by the spriteBatch. And nothing had to be checked.
I don't know if you wanted a solution for this as well, but now you have one.
For the burn effect
Now that we have our terrain in a texture, we can do a post effect on the drawing by using a shader (just like you said). The shader obtains the texture's alpha channel and can now do different things to get our burn effect.
The first option is to do edge detection. Check a few pixels in all 4 directions and see if the pixel is at the edge. If so, it needs to do a burn by, for example, multiplying it with the distance to the edge (or any other function you like)
Another way is quite similar to the first one, but does it in two steps. First you do the same kind of edge detection, but you save the edges in a seperate texture. Now, when you are drawing your texture, you can overlay your edges. So it's quite the same as just drawing the ground at once.
The main difference for the second option is that you can also choose to just draw your normal ground and you are not adjusting the pixel in the ground texture on rendering.
I know this is a long story, but it is a nice technique. Have a look at toon shaders, they do edge detection as well, even though it is 3D.
Keywords: Toon shading, HLSL, Post effects, edge detection, image processing.
Recommended reading: http://rbwhitaker.wikidot.com/xna-tutorials