Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

133 Neutral

About Brisco

  • Rank
  1. Brisco

    Volumetric clouds

    Quote:Is that the 'best' way to do it? I think it is the best way under some special conditions. For shader model 4.0, it would be possible to generate the necessary geometry on-the-fly instead of using a static buffer for the worst case. It may also be possible to improve the method using impostors as described by Harris. Nevertheless, the method works well even for large volume datasets (for example 256x32x256 voxels) and allows a high degree of freedom. But just one comment more: you may need two static vertex buffers, one with vertices aligned to the XZ plane and one with verts aligned on the XY plane. Depending on the view angle, you can then choose the right vertex buffer to minimize artifacts which will of course occur because of incorrect drawing order.
  2. Brisco

    Volumetric clouds

    Quote:Those clouds arent volumetric. They look like simple perlin noise clouds Yes, they are created using perlin noise. Fast animations do not look very impressive using this approach, since it is not physically based. The simple transition rules introduced by Dobashi et al. or the fluid dynamics described by Harris will give you much better results if you want to realize fast cloud simulations; for slow animations, perlin noise should be sufficient. Nevertheless, they CAN BE volumetric, even if they are not in Dubé's implementation. Basically, the noise map values are interpreted as height information (just take a look at figure 2.13 of my thesis). This, of course, leads to the limitation, that clouds are always identical on the top and bottom half, but it may be still ok (don't have tested it). To render them in a way that makes fly-throughs possible, you can simply use a box instead of a plane during raycasting. Of course, you will need some clipping to make sure that the side plane(s) of the box are closely in front of the viewer if the camera is located within the volume. Raycasting can be performed as described in http://medvis.vrvis.at/fileadmin/publications/CESCG2005.pdf I have also tested a combination of these methods - the cloud volume was generated as described in my thesis, using Dobashi's cellular automaton technique and rendering was performed using an improved version of the paper mentioned above. The problem is, that raycasting is really expensive and costs explode for higher screen resolutions, so the framerate drops dramatically if you switch to a resolution that is slightly higher than the previous. That is the main reason why I decided to ignore shader model 2 and below and concentrate on 3.0 hardware, where vertex shader texture fetches can be used to decide if a sprite needs to be drawn or not.
  3. Brisco

    Volumetric clouds

    Quote:It seems like when you render any volume data, you just position a billboard at each voxel. Easy enough. My question is, how do you store/manage this billboard geometry? Cleary you cant do a single draw call per billboard/voxel, so I imagine you create a vertex buffer for several dozen billboards and render them at once. But without monkeying with the vertex buffer every frame, how do you position the billboards at the correct voxel? Or perhaps you HAVE to lock the vbuffer every frame when rendering these kinds of things? Or is there some other 'trick'? Maybe you can find the answer within my diploma thesis. Just take a look at http://www.cg.tuwien.ac.at/research/publications/2007/fizimayer-2007-art/ The method is implemented for shader model 3 hardware; improvements for DX10 hardware could be easily implemented.
  4. Hope this is the right place to post the message. I have written an application that uses floating point render targets as well as floating point texture fetches within the pixel shader. In the results, I got some type of popping when shifting the texture using a direction vector and writing the values to the rendertarget on a Geforce 6800 Ultra. Now I tried it using a 8700M GT and it works fine - could it be possible, that linear texture filtering is not supported for fp32 textures on the 6800 Ultra? I have no other idea what could cause this problem.
  5. Brisco

    vertex shader texture lookup

    Thank you for your answer. I think I will just render my input texture to a floating point render target before using it - because I only need a single channel of the RGBA texture, it should not be a big problem.
  6. Brisco

    vertex shader texture lookup

    I think I found the problem... could it be possible, that only floating point textures are supported on the GF6800?
  7. Hello! For my particle system implementation, I need to do a texture lookup in the vertex shader. The problem is that it seems there is always 0.0 returned (can't be sure about that, because PIX crashes on every computer I tested it when I start vertex shader debugging). VS_OUTPUT BillboardAreaVS(VS_INPUT IN) { VS_OUTPUT OUT; float fParticle = tex2Dlod(SamplerVolume, float4(0.5, 0.5, 0.0, 1.0)).r; if(fParticle > 0.1) { float4 vCameraSpacePos = mul(float4(IN.Position.xyz + vPosition.xyz, 1.0), mtView); float fDistance = distance(float3(0.0, 0.0, 0.0), vCameraSpacePos.xyz); OUT.Position = mul(float4(IN.Position.xyz + vPosition.xyz, 1.0), mtWorldViewProj); OUT.TexCoord = IN.TexCoord; OUT.Size = 4096.0 / fDistance; } else { //just make sure that point sprite is not visible OUT.Position = float4(0.0, 0.0, -1.0, 0.0); OUT.TexCoord = IN.TexCoord; OUT.Size = 1.0; } return OUT; } I used a testtexture for debugging which is completely white, so I guess the lookup should always result in 1.0, but for every single vertex, the else path is used instead. Any ideas what can be wrong with this? The texture is loaded with D3DXCreateTextureFromFile, but I already tried other textures and the problem remains still the same.
  8. Brisco

    how to "discard" vertices

    Quote:There's various point size render states you can set to control the size of point sprites (D3DRS_POINTSIZE*). If those won't get you what you need then you'll need to output a PSIZE value from your vertex shader. Thank you, I tried it with some parameters according to the formula in the DXSDK documentation and it seems that no change occurs. In fact, the sprites have always a constant size in pixels, independent of the viewer position. Of course, I set the D3DRS_POINTSPRITEENABLE state to true - and I have at least a theory: could it be possible, that the state is not relevant if a vertex shader is used? Maybe it is necessary to perform the size computation within the shader?
  9. Brisco

    how to "discard" vertices

    Thank you for your comments. I tried now both, indexed triangle lists and point sprites - and both lead to a significant performance improvement. Geometry shaders are no option at the moment, because I don't have the hardware to implement it. Point sprites seems to be the best solution for me - but I got another problem, it looks like the sprites become smaller near the camera; what I need is a constant world space size, only the projection transformation should modify the size of a particle. Is this possible with point sprites? I didn't use them since DX8. :-)
  10. Brisco

    how to "discard" vertices

    Quote:Are the VBs static or dynamic? A lot of dynamic VB fills could mean you're saturating your bus trying to upload them to the card. Thank you, i thought that one million triangles should be no problem for a 6800. It's just a single VB which is used for 64 draw calls. It is created with D3DUSAGE_WRITEONLY in the managed pool. I also tried the default pool, but the framerate remains constant. The buffer is locked just once during initialization; after that, it is only used for rendering without any modifications. The vertices are quite simple - they just use three floats for the position, two floats for the texcoords and another two floats for as second texcoord set which is used to store the billboard center position for correct rotation towards the viewer. Vertices are organized for rendering as trianglelist.
  11. Brisco

    how to "discard" vertices

    Quote:How many FPS are you getting? You could well be batch limited with that many submissions per frame. If that's the case then you can tweak your shaders as much as you like with only marginal changes in framerate. I changed the number of billboards in the vertexbuffer to reduce the drawcalls. The framerate remains still the same, regardless if the buffer stores 32x32 billboards with 1024 calls, 64x64 with 256 calls or even 128x128 with only 64 drawprimitive calls. I got about 12 fps in any case - even if not a single triangle were in the frustum. I also removed everything from the vertexshader which could be a bottleneck, especially the texture fetch and the condition which was used to decide if a billboard should be moved out of the frustum. The full vertex shader code looks now like this: float4x4 mtWorld = { mtView._m00, mtView._m10, mtView._m20, 0.0, mtView._m01, mtView._m11, mtView._m21, 0.0, mtView._m02, mtView._m12, mtView._m22, 0.0, vPosition.x + IN.BBCenter.x, vPosition.y + 0.0, vPosition.z + IN.BBCenter.y, mtView._m33 }; float4x4 mtWorldView = mul(mtWorld, mtView); float4x4 mtWorldViewProj = mul(mtWorldView, mtProj); OUT.Position = mul(float4(IN.Position, 1), mtWorldViewProj); OUT.TexCoord = IN.TexCoord; So, I think the application can't be batch limited - because 64 calls should really be acceptable... the application can't be fillrate limited because the framerate remains still the same if no polygon is within the frustum. So, the question is: could one million triangles (with 64 drawcalls) be too much for a GF6800 Ultra?
  12. Brisco

    how to "discard" vertices

    Thank you for your answers! Quote:Moving a polygon out of the clipping plane will save you some fillrate, but won't save you the processing cost for the polygon itself Are you sure about that? The texture fetch in the vertex shader is the first thing that happens - and if the texture value is i.e. less than 0.5f, the vertex is not even transformed. But I guess fillrate is the most critical factor in my application, because the billboards are used for cloud rendering and a few hundred thousend of them exist - and all of them need to be rendered without depth test and with blending. It's just an experiment for my diploma thesis, maybe it will be too slow, but volume raycasting with all possible optimizations seems to be even slower than that. Quote:Are you sure that the GPU is the bottleneck for your application? No, absolutely not. For test purposes, I don't use any VFD test at the moment, to there are 16 layers, each with 256x256 particles rendered. The cloud volume is completely generated within the pixel shader and written to a 2D texture which stores all slices. A vertexbuffer with 32x32 billboards in xz-area is used for rendering. To do that, each voxel in the volume is read in the vertex shader - if a cloud particle is there, the vertex will be billboard will be correctly transformed, if no particle exists on the position, the billboard is set out of the frustum to avoid rendering. This method allows to always use the same vertex buffer with 32x32 billboards - only the texture fetch decides if a billboard is rendered or not. Because I did not perform any VFD test and no empty space skipping until now, the vertexbuffer is rendered 8x8x16 times - which leads to 1024 calls (and I know, that this is too much, but as I already said, it's just for test purposes and I already thought about some methods to reduce the number of calls. Quote:For example could the bandwidth to transfer your vertex texture be the bottleneck? Well, I already replaced the tex2dlod instruction by a constant value and got only about 5 frames more per second, so I think that should not be the bottleneck. The reason why I posted the question is, that it is really hard to believe that the framerate is nearly constant when drawing about one million alphablended billboards without depth test enabled or just performing the draw calls while all vertices are transformed out of the frustum by the vertex shader. In my opionion, the application should be fillrate limited, but it seems that this is not the case.
  13. Hello! I try to implement some sort of particle system on the GPU and have a problem with it - the particle data is read from a texture in the vertex shader and some vertices should be "removed" because they are inactive. I thought it would be enough to write position values which are out of the clipping planes, but the framerate remains still constant, even if not a single vertex is within the frustum. Is there any better method to remove billboards which should not be processed without modifying the vertex buffer itself?
  14. Brisco

    DirectInput problem

    Thank you for your answer. The SDK sample works fine - so it seems I really have to compare the code. Nevertheless, I don't understand why USB devices are working... but I will find out. :-)
  15. Hello, I implemented some type of input engines, which simplifies to handle different controller types, but there is a problem with devices connected to the gameport. Joysticks, wheels, etc. which are connected using USB are working fine, they are correctly enumerated and values for axis and buttons are returned. It also works fine for mouse and keyboard, but (as far as I can say) all devices which are connected to the gameport are enumerated, but return always zero for axis and buttons. Nevertheless, the calibration in windows system settings does work - so it should not be a hardware defect. Is there something to consider during implementation for gameport devices? Thank you for your help.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!