• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Noplace

Volume texture for clouds

8 posts in this topic

Hi everyone and please forgive me if I lack fundamental knowledge regarding this issue but graphics programming has always been my passion whenever I get the chance.

 

Now what I'm ultimately trying to do is drawing some clouds in the 3d scene, I'm experimenting with perlin noise from the pixel shader and utilizing a uvw coordinate to generate the values.

 

I set the pixel shader only for a cube which supposedly will be the clouds but I guess my understanding of the concept is not clear on volume textures, because it only renders the sides and never shows the inside:

 

  [attachment=21399:1.png]

 

  [attachment=21400:2.png]

 

 

Am I doing a viable technique for clouds, is there a better/right way to do this? if this is indeed a practical way what do I need to change to render the whole thing with the inside pixels/texels

 

Many thanks!

0

Share this post


Link to post
Share on other sites

There is no "inside": the texture is drawn on the mesh surface if you use meshes.

 

What you want is raymarching (google it).

2

Share this post


Link to post
Share on other sites

As said above... use raymarching.

 

EDIT: Basic Explanation here: http://http.download.nvidia.com/developer/presentations/2005/GDC/Sponsored_Day/GDC_2005_VolumeRenderingForGames.pdf

 

I'm currently building a simple demo that uses the pixel shader volume ray marching approch.

 

Basicly if you draw a cube with vertices located between (0,0,0) and (1,1,1) with some trasform

use the normalize(camPosWorldSpace - VertexPositionWorldSpace) as a marching dir. 

 

Compute the marching dir in UVW space(usually the same vector). 

Compute the ray marching step size.

Start sampling from the current pixels UVW until the current sampling location is greater than 1 or smaller than 0. Accumulate the sampled opacity/trasp for the final pixel color.

 

pseudo

PSMain()
{

   float accumVal = 0;
   samplingUVW = interpolatedVS_UVW;

   while(InUVWBounds(samplingUVW))
   {   
      float sampledValue = Sample(samplingUVW);
    
      accumVal += accumulateFunction(accumVal, sampledValue);
      samplingUVW += someStepSize * marchingDirUVWSpace;
   }
   return color(accumVal);
}
Edited by imoogiBG
2

Share this post


Link to post
Share on other sites

Guys thanks so much for pointing me to the right direction, i have gone through the paper and roughly understand the concept but not enough to do my own implementation so I'm just using the nvidia code, I made some progress I think but not enough:

 

[attachment=21438:1.png]

 

I'm using the exact code from here: http://developer.download.nvidia.com/SDK/9.5/Samples/MEDIA/HLSL/volume.fx but just converted to hlsl

 

1- regarding the boxMin and boxMax, do we have to account for the world transformation of the cube? at the moment I'm just drawing the cube at 0 so it should not affect the result 

 

2- I'm using d3d11 and by default all matrices are transposed before sending to the shaders, however for view inverse I'm sending it normally because if it is transposed the results are messed up ( and based on debugging the correct results are sent without transposing it)

 

So any idea what I'm doing wrong? I'm just drawing a cube here and running the VS and PS from that code on them, this is my shader code for reference:

 

VS:

struct VertexShaderInput
{
	float3 pos : POSITION;
  float3 uvw : TEXCOORD0;
};



static const float foclen = 2500.0f;

void RayMarchVS(inout float3 pos : POSITION,
				in float4 texcoord : TEXCOORD0,
				out Ray eyeray : TEXCOORD1
				)
{
	// calculate world space eye ray
	// origin
	eyeray.o = mul(float4(0, 0, 0, 1), viewInv);
  float2 viewport = {640,480};
	// direction
	eyeray.d.xy = ((texcoord.xy*2.0)-1.0) * viewport;
	eyeray.d.y = -eyeray.d.y;	// flip y axis
	eyeray.d.z = foclen;
	
	eyeray.d = mul(eyeray.d, (float3x3) viewInv);
}


VertexShaderOutput main(VertexShaderInput input)
{
	VertexShaderOutput output;
 
	float4 pos = float4(input.pos, 1.0f);

	// Transform the vertex position into projected space.
	pos = mul(pos, model);
	pos = mul(pos, view);
	pos = mul(pos, projection);
	output.pos = pos;
  RayMarchVS(input.pos,pos,output.eyeray);
  output.uvw = input.uvw;
	return output;
}


PS:


static const float brightness = 25.0f;
static const float3 boxMin = { -1.0, -1.0, -1.0 };
static const float3 boxMax = { 1.0, 1.0, 1.0 };

// Pixel shader
float4 RayMarchPS(Ray eyeray : TEXCOORD0, uniform int steps=30) : SV_TARGET
{
	eyeray.d = normalize(eyeray.d);

	// calculate ray intersection with bounding box
	float tnear, tfar;
	bool hit = IntersectBox(eyeray, boxMin, boxMax, tnear, tfar);
	if (!hit) discard;

	// calculate intersection points
	float3 Pnear = eyeray.o + eyeray.d*tnear;
	float3 Pfar = eyeray.o + eyeray.d*tfar;
		
	// map box world coords to texture coords
	Pnear = Pnear*0.5 + 0.5;
	Pfar = Pfar*0.5 + 0.5;
	
	// march along ray, accumulating color
	float4 c = 0;
	float3 Pstep = (Pnear - Pfar) / (steps-1);
	float3 P = Pfar;
	// this compiles to a real loop in PS3.0:
	for(int i=0; i<steps; i++) {		
		float4 s = volume(P);
		c = (1.0-s.a)*c + s.a*s;
		P += Pstep;
	}
	c /= steps;
	c *= brightness;

//	return hit;
//	return tfar - tnear;
	return c;
}

float4 main(VertexShaderOutput input) : SV_TARGET
{

  return RayMarchPS(input.eyeray);

}

0

Share this post


Link to post
Share on other sites

however for view inverse I'm sending it normally because if it is transposed the results are messed up

For proper conversion, one should use the transpose of the inverse, not the inverse. You calculate the inverse as a row-major matrix (CPU side) and stuff it into the shader. The shader (GPU side) uses that value as a column-major matrix, which is, in fact, the transpose of what you stored. All done auto-magically. wink.png

Edited by Buckeye
0

Share this post


Link to post
Share on other sites

Well the paper implements a bit different rendering idea, but the ray marching algorithm is the same.

The approch that was described into the paper is working like post process.

I've drawn a picture that maybe will explain those things better.

 

http://imgur.com/laPDGE5

laPDGE5.png

 

Currently I cannot share my code(It is not something spacial).

 

About the matrices issues: I dont know your CPU side math so I can't help.

Edited by imoogiBG
1

Share this post


Link to post
Share on other sites

thanks imoogiBG ! I followed your description and code for the VS and now it is working correctly

 

only thing left now is fine tune the volume function biggrin.png

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0