Jump to content
  • Advertisement

mmixLinus

Member
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

126 Neutral

About mmixLinus

  • Rank
    Newbie

Personal Information

Social

  • Twitter
    @mmixLinus
  1. mmixLinus

    Starfield shader pipeline

    Good comments, thanks! @Norman Barrows - What you mention in your edit is exactly my problem. Some stars are points, some are quads. And thanks for writing up on the "degenerate quads" idea, that sounds like a good idea, and may mean I can lose the geometry shader :)   However, there is a hitherto unmentioned problem looming ahead, see below... @phantom - Yeah, I read somewhere about the inefficiencies of the geometry shader, so I'll have that in mind.   @Hawkblood - Yes, parallelism is fun, hehe. I started off with >2 million points, running at ~200 fps (pleasant surprise, on my "low-end" GT220).  I'll let you know if I figure out the mouse pick feedback problem!   @Ryan_001 - Ok, had to lookup BVH, :D and though I've never thought about raytracing, I HAVE been thinking about partitioning the data, because of the following problem..   Just so you know, I'm using the "TGAS" database released by ESA in September last year. It contains very accurate positions of these 2e6 stars.  However, this database is just a taster.  The database they are building, using their Gaia satellite, is going to hold 1e9 stars! Yes, one BILLION  :ph34r:   Now even with clever vertex compression and fixed-point or integer data, I think I am going to struggle getting that much data to the GPU, let alone making good use of it in realtime. So, I will probably need to do whatever I can to make this as lean as possible, AND use efficient data partitioning I suppose. I'm currently looking at Transform Feedback / Stream Output. Perhaps I can get points through to the rasterizer, and feedback some quads to the IA?  I'll probably soon try @Norm's idea of sending ALL quads to the GPU, should be fast in the GPU, though significantly more data to transfer to the GPU.
  2. mmixLinus

    Starfield shader pipeline

    Thanks Norm & phantom for your replies!   I did a little experiment with my geometry shader:  Emitting one quad (non-textured) for each point that it receives.  This sort of confirms my suspicion.. that it is too heavy for millions of points.  It works but is too slow.   If you look at photos of star skies you can see that most stars are faint, and these stars could probably be represented by a simple one-pixel point all the way up to MaxWhite.  But even brighter stars are "large" in the photos, ie., they cover an area (many pixels). This is largely due to interstellar gasses, and lens effects.  To emulate this "behaviour" I was thinking of showing a quad for only the brightest stars.  How do I accomplish this selective choice of "pass-thru or NULL geometry shader" for most stars, or rasterize a quad for "a handful" of stars?".  (I don't want to do this on CPU side :) )
  3. mmixLinus

    Starfield shader pipeline

    Found this, within Gamedev, suggesting instancing to create my quads (not using the geometry shader). Interesting!
  4. mmixLinus

    Starfield shader pipeline

    I should mention that I've googled a fair amount, read articles etc on msdn and others, but I think I need more concrete examples to understand how the bits fit together. Or pseudo examples :)
  5. :) Hi folks, first post here :)   I am a seasoned C++ coder working on a "starfield visualizer" (called "Galaxy Navigator 3D" by the way) and I need some help understanding my alternatives regarding shaders. An early version of the program is up on youtube, but frankly, starfields aren't best friends with video compression :D  (Try viewing in full HD). Or you can download it here.   The navigator currently displays a "point list" of more than 2 million points (stars). Each point has an associated 3d position, and a "brightness" (aka Magnitude in astronomy). As you move around in space, the brightness of all stars is recalculated (in my vertex shader) so as you move closer to the stars they become brighter, all according to standard magnitude calculations used in astronomy.   I am using Ogre3D 2.1 as render library, with Direct3D11, HLSL (but I intend on making this cross-platform in due time..). It currently uses rather simple Vertex, Pixel and Geometry shaders that I have written. It's all simple and "sequential", because I'm still pretty new to this :D   Goals: 1) Really close stars need to be "even brighter" than a point (pixel) at colour (1.0, 1.0, 1.0), which I suppose should be accomplished by issuing textured quads for the closest points. 2) Interactivity: The user should be able to select a point (with a mouse) for some interaction, and also interact by simply hovering with the mouse pointer.   Problem1: I already easily detect which stars are the closest (I change their colour for indication), but I don't know how to emit quads from my Geometry Shader. I understand a GS can emit to several streams, but that seems to require Shader Model 5.  Preferably,  I would like to solve this without putting too many requirements on hardware, so currently using SM4. Is this a bad choice?. Can I get my GS to emit most of the points to the rasterizer, and a handful to a buffer containing quads? Maybe this requires a second pass? or another GS instance. I don't how this works : (   Problem2: Because of the number of points (which is going to grow), and because of the "ease", I think mouse picking would be best done in the GPU. Currently, I send the mouse position to the vertex shader, so it can identify which stars are "close enough". This works.  I change the colour of the points closest to the mouse pointer.  How do I get these points back to the CPU? The actual information sent to the CPU isn't defined yet, but it might by a 32-bit integer ID of sorts. Or maybe some floats. Say a maximum of 100 points, but typically no more than 10. Some sort of staging buffer? I don't know how this works either. Does the method of choice depend much on shader model?   All help appreciated! /mmixLinus;      
  • 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!