Trying to overlay a view cone on top of a grid

[CarstenT]

@zxuiji,
All geometry you learned in school would take place in a standard coordinatesystem: x & y orthogonal and unit-length of both are equal.
You’ve ditched that outset.
Can you read, write to or entrepret any visual output in such a frame of reference? It does not seem to be the direct way to make things easier.

The “view cone” is an advanced concept that cannot be simplified more than to the orthonormal projection. The viewport takes one line to implement and works in the background. Untill you use it, you’ll have to see x approximately twice the size as y.
I suspect that you talk about a “cone” because that may be what orthonormalized coordinates may look like in the asymmetric coordinate system you have now.

[zxuiji]

er, no, x & y are not always equal, take a right angle triangle and take 5 points along the hypotenuse, 0%, 25%, 50%, 75% and 100%, let’s say the length of the adjacent and opposite are both 100 units, doesn’t matter which unit, just 100 units, the xy coords will result as follows:

0,100;25,75;50,50;75,25;100,0

Does that look equal to you? of course not, but those very same values are what lead me to the math I’m developing, once their normalised it’s only a matter of multiplying against the difference between the base positition and the out limit position to get the relative position between the two of the same point.

[CarstenT]

the point is, that the units that you expresses the coordinates in IS what I talk about. If they do not represent equal size in a orthographic system they will not make sense.

[zxuiji]

Again, the units don’t matter in this case as what I’m trying to calculate is the relative percentage which can then be applied to the numbers in whatever unit they happen to be in, this is basically algebra where you get rid of the units that don’t matter leaving you with what you actually need, everything else is secondary.

[CarstenT]

@zxuiji

On a somewhat related note (as in same file, pertains to the view cone), do you have any experience using deltaTime type variables against small integers? As in 0 - 100, tried but no movement occurred until I upped the limit to 1000 which had the knock on effect of slowing things too far down instead.

Not much experience but finding my new pc has a much finer-grained clock with higher accuracy. It should at least count in milliseconds. Check out the values you get (by cout << ) in both your style of drawing, and the way I suggested. I expect your problem may relate to slower drawing, but test it out. Such simple drawing should happen at least 100 pr sec.

@zxuiji

I’m after a dynamic image because I’m testing math that skips raycasting and directly calculates the point looking at

Do I have any chance of understanding this?
Do you have a look-at point? This makes sense with a camera/projection-matrix setup … you’ve chosen your own model. What would that be?

@zxuiji

Well the point of opengl is dynamic images on screen

I would rather say the abillity to draw millions of triangles in a blink. It’s up to you where to place them properly.

@zxuiji

I thought of a method to take any angle and calculate the relative x/y axis that looking at, has potential to scale to 3d also,

Do I have any chance to understand this. What context does this make sense in?

@zxuiji

you’re familiar with ray casting right? Where it takes steps through the map to find the first object visible to a player

Raycasting and a specific game-model are two things that you cannot add together and expect me to understand what exactly you mean.

@zxuiji

well I intend to go a different route, instead first calculate the outer limits of what to draw then, while going through the objects list adjusting their positions, fill an array of what to draw in front of the player and draw that instead of the map, in other words the map will never be sent to the GFX card but instead just the small array of objects.

Well. Good to have a plan.

@zxuiji

Right now however I need the code environment kept as simple as possible for both me and others to understand how the math effects the “view cone”

Do you have a view-cone? Can you tell me about it? That’s a 3d thing, right? This is a thing that is hard enough to tackle knowing all the intricacies of opengl and the associated math-libraries. Since it’s a cone … it’s properly projective with things shrinking at a distance.
One of the problems about this stuff is, that one quickly looses sense of ‘space’, orientation and looses your abillity to ‘envision’ sharply enough to do anything properly. This is partly what matrix-speak solves.
With the image of a view-cone in mind, you have the full setup of a camera at a specific 3d-point, a specific direction and some specifics to look at, right? Or does your view-cone have a bit less rigorous meaning?

sorry if I come out stupid.

[zxuiji]

Ok, gonna respond to the last point for now, I’ll re-read another time and respond to them then (a personal project so no rush on my side), this is neither a game nor a 3d environment, I just needed the environment to test the math is correct, so far I’m at the halfway stage where I can generate the relative points piece of cake but applying them correctly is the hard part, I actually did the 1st half on my phone by just iterating by 25 from -100 to 100 and applying the same math to generate the relative points for each axis, all I needed was the angle and the max angle to generate those points, applying them is the hard part

[zxuiji]

@CarstenT

Raycasting and a specific game-model are two things that you cannot add together and expect me to understand what exactly you mean.

Coding Challenge #145: 2D Raycasting

[CarstenT]

@zxuiji

Still could use help on using my deltaTime variable with a small integer of 0 to 100 though

I asked if you would test your timer-variables for a reason. Your drawing-loop contains what must be seen as obstructions that will delay the time it takes to draw … that may be why your deltaTime come out too large.

@zxuiji

I thought of a method to take any angle and calculate the relative x/y axis that looking at, has potential to scale to 3d also

You talk a lot about math and shows preciously little. I looked at your points generation in your other post. For anything to have just a little meaning, those points should be generated as normalized device coordinates, right? The values will all be less than 0.0f and may not appear on screen.
Your points ‘could’ provide you with a predictable place on the screen … like a piece of paper to draw on, if done right. If you bring in matrixes later on, you’ll have to ditch all the ‘math’ that you’ve shown.

@zxuiji

I can generate the relative points piece of cake but applying them correctly is the hard part

… don’t worry. They’ll be gone by the time you set up things straight.

Thank you for enlighten me on raycasting, but the question was about how a gamemodel & raycasting relates to … whatever you’ve made through your math and that fails to draw properly.

The advantage of a normal coordinatesystem is, that you ‘live’ in it: nose forward, head up … You will have to ‘think’ normalized device coordinates to make your stuff work. No wonder that you have problems applying anything.
… if that’s what’s going on.

[zxuiji]

I’ve been dealing with normalised co-ordinates from the get go, either way the math wasn’t what I needed help with, you’ve helped me understand a bit better how to initialise things I need to test my math and as far as matrices go I’ll give them a try AFTER I get my math working since I’m certain it can be translated to GPU code, for example the calculation of the view cone can be done in software mode (cheap operation I expect given there needs to be code handling the “player” anyways) then the values can be passed onto the shaders, the shaders then use those variables to decide if it’s worth drawing the object in the first place.

[CarstenT]

> I’ve been dealing with normalised co-ordinates from the get go, either way the math wasn’t what I needed help with, you’ve helped me understand a bit better how to initialise things I need to test my math and as far as matrices go I’ll give them a try AFTER I get my math working since I’m certain it can be translated to GPU code, for example the calculation of the view cone

If you abandon the ordinary opengl consepts, noone has a clue of what “the view cone” is.
The one I can imagine is emanating from my eyes along a direction to a near plane perpendicular to the direction … and continues to the parallel far plane. A 3d thing that needs a coordinatesystem with understandable coordinates to be expressed in.
It’s usual to refer to “the world” as the dimensioned space you intend to act and draw (models) in. The world is your playground where you’r free to fantasize, but sooner or later you’ll need to fix your view-cone in this space. Do you think that you are free to ‘fantasize’ in ndc-space? How will you describe that world to me, in an understandable way, if not in reference to a normal coordinatesystem? It will be difficult for you to figure out simple geometry to draw as model if you have to express them in ndc.

> can be done in software mode

You mean on the cpu side, with gpu-code as the specific opengl-code?

> (cheap operation I expect given there needs to be code handling the “player” anyways) then the values can be passed onto the shaders, the shaders then use those variables to decide if it’s worth drawing the object in the first place.

This sounds like clipping. Opengl is in some degree automated to deal with this.

If you have screen-values as
int sc_width
int sc_hight

the plain conversion to ndc
vec2 my_coords,
vec2 ndc_coords = vec2(my_coords.x/sc_width , my_coords.y/sc_hight)

if you want your d2 world to have other dimensions than screen-width/height, you factor a scale. This is ideally what the viewport-transformation does (specialists may object, I’m not one). The third .z 3d-coordinate follows an axis perpendicular to your screen, positive toward you, if you want 3d.

Now, you can work in ordinary space and, as the viewport does automatically, you’ll need to normalize before sending coords to the shader.

There is a ‘default’ camera sitting at (0,0,0) looking in -.z direction. This may be why you only manage to see the ‘upper right’ part of your geometry in the lower left part of your screen.

This suggests, that you need to do a new transform.
vec2 ndc_coords = vec2( (my_coords.x/sc_width) + 0.5 , (my_coords.y/sc_hight) + 0.5 ) ?
You draw here on the xy-plane for z=0. You may have to add z = -1.0 to your coords to prevent automatic clipping. This is an orthonormal projection. Layering could be achieved by drawing the top last.

I’m not going to follow you further than here, unless you involve the proper viewport transformation, use rational coordinates and have simple geometry appear on screen where expected.

[zxuiji]

Just because a cone typically means a 3d object doesn’t mean it doesn’t also get used for triangles on a 2d plane as it is both easier to say and write, I’ll continue reading your message now, just seemed like you weren’t comprehending it no matter how many times I thought you would, I thought it was natural to think of terms used in native language that a player would likely use, only supposed to use technical terms when either there is no other available or getting into the nitty gritty stuff that a player wouldn’t normally see.

[zxuiji]

@CarstenT

if you want your d2 world to have other dimensions than screen-width/height

That part’s actually WAY easier than the view cone, just split the “world” into cells and only load upto 36 cells at a time, 27 for the immediate area, 9 for the view beyond the normalised space of the player. whenever the player crosses the normalised -1/1 point 1/-1 is added to put the player back in normalised space and the 9 cells that just stepped into become the middle cells and I’m sure I don’t need to explain further do I? It’s simpler to record which cell and the normalised position in that cell than to try and resolve infinity issues.

[CarstenT]

@zxuiji

Just because a cone typically means a 3d object doesn’t mean it doesn’t also get used for triangles on a 2d plane

Since you’r new in opengl, I assume that you get comfortable with 2d before you proceed. That means that the cone you talk about is a box spanning
(0,0,-infinity)->(width,hight,+infinity) … or something to that effect.
You sound as if you want to skip opengl and right away fix a transform that involves a free view-point and -direction to get rid of the mess between your player-world and it’s presentation on the screen. Because you specifically call this box a cone, you imply that you’ve added a projective view on things on top too. Why is it that you don’t expect hell to break loose if you attempt that?
…
I’m not a player. I’m a modeller.

[zxuiji]

Doesn’t sound like you’ve understood what I’m doing, basically I first needed to get opengl opened and drawing anything, that was accomplished and I’m using rand_r(0) to generate a bunch of points as the base layer where z is always 0, next I started placing the “player” who’s z axis is also always 0, next I started work on getting the view cone to appear with fixed start point and z is always 1 for that, next I started with my math for changing the x & y values for the points of the view cone, that’s fine, that’s my issue to fix, the reason I’m only touching x & y points is because an angle only effects 2 axis, by calculating the normalised points of both axis it is then possible to just multiply those values against the difference between the player position and total size to provide the exact place those points should be

[CarstenT]

whatever,
you don’t have a view-cone anywhere, and I’m not trying to enforce one on you. You have a viewing box with center in (0,0). You parade what you wants to see down passed this through point-translations.
It’ll work.

[zxuiji]

I mean rhe view cone from the player to the view port boundaries in this scenario, when the math is working it can be used for the viewport if needed, though I intend it to be mainly used for processing what cells to load which will then help decide what objects to load, the shaders or whatever can then take the values calculated

[zxuiji]

going from what I’ve been reading in the FreeType docs I may have been using matrices unkowningly, I’m at work so I can’t post what I mean until I get home

[zxuiji]

Whoops, forgot to post this last night, lost the url for where I found something that made me think I might already be using matrices CPU side, lemme know if this is along the right lines or I misunderstood something

float grid[POINTS][3], view[VIEW_POINTS][3];
...
void init_grid( unsigned int seed, float px, float py, int pa )
{	
	/* Grid */
	int c = 0, p = 0;
	float row = 1.0 / ROWS, col = 1.0 / COLS;
	float rx = row * (ROWS - 1), ry = col * (COLS - 1);
	
	row *= 2;
	col *= 2;
	
	memset( grid, -1, sizeof(grid) );
	
	init_view( pa, max_angle, px, py );
	
	/* Player Position */
	grid[p][0] = px;
	grid[p][1] = py;
	grid[p][2] =  0;
	++p;
	
	for ( int i = 0.0; i < ROWS; ++i )
	{
		if ( i == 0 || i == (ROWS - 1) )
		{
			for ( int j = 0; j < COLS; ++j, ++c )
			{
				grid[p][0] =  (col * j) - rx;
				grid[p][1] =  (row * i) - ry;
				grid[p][2] =  0;
				++p;
			}
		}
		else
		{
			grid[p][0] =  -rx;
			grid[p][1] =  (row * i) - ry;
			grid[p][2] =  0;
			++p;
			
			for ( int j = 1; j < (COLS-1); ++j, ++c )
			{
				if ( rand_r(&seed) % 23 == 0 )
				{
					grid[p][0] =  (col * j) - rx;
					grid[p][1] =  (row * i) - ry;
					grid[p][2] =  0;
					++p;
				}
			}
			
			grid[p][0] =  (col * (COLS-1)) - rx;
			grid[p][1] =  (row * i) - ry;
			grid[p][2] =  0;
			++p;
		}
	}
}

[CarstenT]

I don’t have the foggiest idea about what you’r doing.

[zxuiji]

Just generating something to overlay the view cone on top of, later I plan to learn how add transparency to the view cone before moving onto understanding the matrix functions. This project is only partly for developing the math, the other part is learning how to pass data to and from the GPU and how to tell the GPU to do what I want it to do