Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Jul 2013
Offline Last Active Oct 10 2016 07:56 AM

#5148895 About fixed points

Posted by on 23 April 2014 - 01:09 AM

Whoah ! Thank you all so much for all your help !
I start to understand. There is just some things to learn more...
For the moment, I will concentrate myself on only a planet, I will see later for solar system, galaxies, etc.
For very high precision, you say it's better to use int64. I think I need to create a class for converting it to better readable numbers (for coding) ?
If not, with micrometers precision, I will deal with very very big numbers (without digits as it's integer), not very convenient.. ? Some tips ?
I understand the concept of  using camera position as the center, for more precision when converting to float.
But subtracting the vertices x,y,z from the camera position in the CPU will be huge ?! There is lot of vertices in the node's grid (x 6 faces)...
Better to do that in the vertex shader, no ? But if I do that, how to send the coordinates to the shader ? 
As the max input is R32B32G32 and I will use 3 x int64... ?
My grids are allways the same, they are offseting and scaling in vertex shader based on node position and LOD.
In conclusion, when to convert to float and where ? What format to send to the shaders ? 
Again, thank you for all your help ;)
PS : I know it's a hard concept for a beginner, but I'm here for learning and not affraid to spend hours on that.

#5129256 Help for gameplay's ideas about a little space demo game

Posted by on 06 February 2014 - 02:58 AM

I'm an indie dev, which working after work. I allways wanted to make my own graphical engine (DirectX) for procedural content.
My final goal is a full 4X game with a complete story line, separated in episodes (where each introduces more content).
Now my engine is in alpha version and I'm thinking about creating a little game for demo purpose.
Features that will be available :
- Procedural planet generation (not complet, but advanced)
- Volumetrics lights, clouds and dynamical weather
- A physical engine for flying
- Except precomputed atmospheric scattering, all parameters can be changed in real time
I hope, for the demo, to make a max real physical simulation, where a little spaceship comes from space at great speed, inserting in orbit for slowing down.
After, inserting it in low orbit, going down and touch down a station.
For that, I don't want an arcade style game, but a much more simulation where errors are not permitted.
Managing flying parameters, coordinates, gravity, system power for shield, engine, etc... View from cockpit.. 
A success to touch down without damages must be very difficult. (yes I'm a star trek fan)
I have the main idea in head. But... It's not very funny.. How to add some "attractive" stuffs ? Like mission to achieve, time score, rising levels... ?
What do you think ?
That will be just a first little indie game for demo (and free !).. Not a big AAA ;)
And I'm alone for making it....
Thank you
PS : Sorry for my poor english.. 
Some screens from actual dev version (so much work to do.. and bugs to correct)

#5096128 [SOLVED] Tessellation on IcoSphere

Posted by on 23 September 2013 - 06:43 AM


Nevermind... Forget all my posts....

All the troubles were caused by the SDK June 2010 !!!

All is working very well now !! ;)


Thank you again for your help !!


If someone has the same problem, you need to add this in the hull shader file :

#if D3DX_VERSION == 0xa2b
#pragma ruledisable 0x0802405f

All this drawing and posting time just for a little bug.... 

#5095117 [SOLVED] Tessellation on IcoSphere

Posted by on 19 September 2013 - 02:18 AM

Hello ;) Before, sorry for my poor english... 
I'm working on a procedural engine with some results on generating a full planet.
But I have a "crack" problem with the tessellation (based on frustum and distance LOD).
The icosphere is generated by code with X subdivisions. Let's go with 0 subdivision for theory..
I'm using this algorythm for adaptive tessellation :
Every vertex's distance is calculated and the minimum is used for defining the tessellation factor on the edge.
So, in theory, there will be every time the same factor for the same edge, and in result, no cracks !
But, there is a problem.. Which vertex for which edges ?
I need to address tessellation factor for each 3 edges in a hard order.
Edge 1 from triangle A must be the same edge shared by triangle B in the same order (egdge 1).
(in the exemple here, vertex variable is the tessellation factor calculated from distance to camera)
HULL SHADER (patch function)
_output.Edges[0] = min(_vertex2, _vertex3);
_output.Edges[1] = min(_vertex1, _vertex3);
_output.Edges[2] = min(_vertex1, _vertex2);
_output.Edges[0] = min(_vertex2, _vertex3);
_output.Edges[1] = min(_vertex1, _vertex3);
_output.Edges[2] = min(_vertex1, _vertex2);
So, if the edge shared by A and B is edge[1], A.vertex1 must be the same vertex as B.vertex3....
If not, there will be differents tessellation factors and cracks...
Whith a flat grid, this is working very well (every edges shared are in the same order) :
But for an icosphere.. It's not possible (view eclated from upside) :
The order is wrong......
I'm using 3 points patch list, I tried with 6 points patch list (neighbors), but it's the same problem...
I'm not sure to have correctly explained the problem.
My general question is : How to do tessellation on icosphere without cracks ?
Is there a better algorythm ?
I'm far from an expert in graphics.. 
Thank you very much for any help ;)
Here some screenshots from actual rendering results :

#5076584 DirectX 11, using Tessellation & Geometry shader in a single pass

Posted by on 10 July 2013 - 06:01 AM

I never talked about my other goals with this project... It's a lot of work, I know, but I'll try ;)


One pass will never be sufficient for all my needs..


- GPU terrain rendering with "unlimited" details (from planet scale to one meter)

- Terrain self shadowing from directionnal light (pretty results with shadow map and blure now)

- Ability to hand modify the terrain, store and re-use the modifications (no ideas for the moment...)

- Terrain logics, featuring differents noise parameters to have mountains, oceans, etc....

- Terrain logics, rivers and other stuffs...

- Collision detection (perhaps in GPU with compute shader)

- ...


Before, I made a project like this, but with flat, limited, pre-computed map.. Not spherical, not noise in GPU...

I know that I cannot have a real-time algo for all this stuff, there will be some pre-computed data (like a logical map with zones, river, etc.).


My actual graphic engine is sufficient for tests and going forward.. I miss the global logic/architecture now.. It's more a brain problem, not technic ;)


Perhaps, do you have some suggestions, ideas for generals steps ?


Thank you again for your time and your help !!


PS : I tried to calculate the normal in the noise algo, using derivatives.. Not so easy but I have some results.. But not good enough, I think I'm missing something...

Perhaps, for other needs, I will use the compute shader and so, use it to compute correctly the normals...