znichola / minirt Goto Github PK

poi_sphere should be returning the distance to the poi from the origin, not an int 1/0. I tried changing the tests to fix, but can't run them to check.

Represent the currently selected object, and create the accessor functions that return a pointer to the position colour etc, whatever we might want to change via a keybind.

orientation vector can't have any terms negative when loading from map, idk it's a strange bug as it's the same validation code as the other shapes which can...

Just an ides, idk if it's worth exploring, but we can make a lookup table to convert 0-255 int to float. As we'll be doing that quite a bit I think.

The cone height is going above what's possible and it's reading into the next texture, which would be it's bump map as it's loaded right after.

The t_image_data is a struct that we need to free if we want to overwrite loaded image data, so something to free it!

They currently very strongly affect the direction the light is overall coming from but show little gradual effect. And the results just seem to be wrong.

• - Cylinder
• - - it is broken, must fix
• - - - poi on cap
• - - - normal on cap
• - - - normal on body, all cases, don't cheat with the weird inside out cylinder
• - - Refactor sphere to use new poi variable
• - - FIx plane rendering
• - Object selection UI indicator
• - Object property modifier
• - Finalise the frikin' parsing
• - Refactor pix shader to use t_intersection
• - Plug leaks!
• - - Do more thorough tests

Bonus !

• - checkerboard
• - - cylinder uv unwrap!
• - texture integration
• - - cylinder uv unwrap!
• - skybox
• - multithreading !?
• - cone!
• - - same todo list as cylinder

For now...

internal structure needs to be able to hold texture, bmp and normal maps and the parsing should support any number of them.

The files are stored as a char* that is the string to the path of the file.

This is just to get some ideas down on paper, the possibility to modify stuff on the fly is kinda important for the dev process and also because it's cool.

// int	scale_property(t_app *a, float *property, char *ctrl, int key, float factor)

scale_property(a, &a->l_origin.z, "my", e_mouse_right, 1);

This is the function we have now, we can "animate" any property with a change in one of the two mouse axis.
For instance the configuration above will modify the light's z value when the right button is held based on the distance the mouse has moved since the last frame.

scale_property(a, &a->sp_radius, "ky", e_key_s, 0.2)

Or for instance the radius is modified while the "s" key is held with the a scaling factor of 0.2.

The limitation of this interaction model is that each action must be mapped to a unique key and only happens while it's held.

this only seems to happen for the sphere

t_v3	pix_shader(t_scene *s, t_object *me, t_v3 poo, t_v3 poi)
{
	t_v3	obj_col;
	t_v3	ambiant;
	t_v3	diffuse;
	t_v3	specular;
	t_v3	poi_norm;

	poi_norm = v3_unitvec(v3_subtract(get_obj_pos(me), poi)); // need to pass this to other functions for opti!
	obj_col = get_obj_emmision(me, poi);
	ambiant = v3_multiply(s->ambiant.colour, s->ambiant.ratio);

	t_v3	tmp = ORIGIN;
	if (find_poi(s, v3_unitvec(v3_subtract(poi, get_light(s, 0)->position)), poi, &tmp))
		return (col_multi(ambiant, obj_col));
	else
	{
		diffuse = get_light_diffuse(s, 0, me, poi);
		specular = get_light_specular(s, poo, poi, poi_norm);
	}

	// specular = ORIGIN; // uncomment to switch off spec component.
	// diffuse = ORIGIN;
	// ambiant = ORIGIN;
	// obj_col = (t_v3){1.0f, 1.0f, 1.0f};

	// return (col_multi(col_add(col_add(ambiant, diffuse), specular), obj_col));
	return (col_add(col_multi(col_add(ambiant, diffuse), obj_col), specular)); // I think this is correct but it's not how the openGL site explains it.
}

We need to check if the light ray hits another object after a bounce, this can be kinda annoying, maybe the solution is the refactor find poi so it doesn't look for intersections with an object.

trace a ray from the mouse position at click and shoot a ray to select an object in world space.

The error messages are incorrect. It always outputs: invalid identifier on line ....
This is because i used some tricks to reduce the number of lines of code in the parse() function.

There should not be a shadow on the red sphere as the light is not being intersected, it's difficult to tell but this seems logical.

The green sphere is behind the camera, but it still shows up as in view. Interestingly it's normals seems to be inverted per pixel.

Found this bug while doing the shadows and was getting un-explained results.

The shadow at a pixel is calculated from the colour of the first intersecting object when going from the surface towards the light.
You can see that any objects along this line count as an intersection for this pixel which is not correct.
https://user-images.githubusercontent.com/12100623/227728794-09ea7a1c-efd3-4770-8045-4d6fc44204df.mov

emus order is mismatched so things are extremely wonky, it's impressive the level of mess C lets you get with.

Use instruments -> time profiler and hook on to running ./miniRT

The keybinding should be able to bind the selected object and print only the changes variable to the terminal correctly named.

Extending this: changes variables should be displayed on the screen.

it's a bug, needs fixing!

When the light is behind the sphere the sphere is actually illuminated from the front and it's inverted when moved behind. Probably an easy fix.