| Age | Commit message (Collapse) | Author |
|---|
|
Wanted to be able to for example move around freely in the scene but
also have something that would for example follow key frames and
render a gif.
Abstracted it with a scene controller. You can hook up keybinds and
other thigns for it as well. Right now there is only the interactive
scene controller which keep the behaviours previous to this change.
Now I could possibly switch it out with something that uses key frames
to render several images to create for example a gif.
List of other Misc changes:
- Add configuration setting for scene controller (`scene_controller`)
- Add configuration setting for renderer
- Add configuration setting for preview renderer (`preview_renderer`)
- Add clone to Config.
- Add from implementation for Renderer to be created from the config
object.
- Add cancel event to image action. An action could be blocking when
the application wants to exit. Actions can now listen to the cancel
event to exit early and not block.
- Fixed bug where WaitForSignal action would block after application
tries to exit.
- Add method to KeyInputs to be able to take a list of callbacks instead of
manually registering every callback one at the time.
|
|
Removed render.rs and added a renderer trait.
Planning on making several implementations so it makes sense to move
it to a trait so you can change implementations.
|
|
|
|
Did a test where I removed all the operators for vec and forced the
user to use functions on the vector instead that mutated the existing
vector.
You had to manually call clone if you actually wanted a new vector.
No automatic copies were done. Expected the performace to increase by
quite a bit since most of the operations are vector operations.
Chaining operations like the following just mutated the existing
vector.
```
vec.mul(vec2).div(2).add(vec3);
```
Could do this pattern for most things.
Turns out is's not such a big deal.
Set up a test case of the simple scene with 3 balls. The difference in
performance was about 1%. Got surprised and made a more complex scene with
over 400 objects expecting to get a bigger difference. Nope. Still 1%.
Decided it was not worth it since it was a bit more annoying working
with the vectors.
Probably get better performance gains with SIMD or using the GPU.
|
|
println works for a while. Was time to set up something better. Worth
to not that there is a big difference between logging and writing to
the terminal which is why both slog and console was dragged in. Might
seem similar but purpose is not the same.
Most of the time the log is interesting during runtime but user
messages does not belong in the log.
|
|
|
|
When aborting during the render while the png action was selected it
would abort it and start another one.
|
|
- Was pointless to have one event for render and one for
cancel. Reduced it to one while fixing a minor bug.
- Remove useless dereference and borrow. Not sure how it
ended up like that.
- Moved around some code.
|
|
Just wanted to add defocus blur but ended up changing a bunch of other
this as well.
- Moved scenes to a separate folder.
- Updated readme with more pretty images.
- Add interface for loading scenes. There is currently one for yaml
and another if you want a slightly random scene.
- Add image action to decide what to do with the final image once its
rendered. Currently supports just showing the buffer until you press
the render buffer again and saving the image as `png`.
- When you use nix shell you will be dropped in the proper folder so
you can just do cargo build etc without having to do `cd`.
|
|
- Set position of camera.
- Set look position of camera.
- Set FOV
|
|
|
|
Once the render is done it saves an PNG.
|
|
|
|
Refactored how the threading worked. Before it just keept up splitting
the screen recursively for x number of times.
Felt like using recursion was unnecessary. It's now just done in a
loop instead. The user can control the behaviour by setting
`num_threads_width` and `num_threads_height` which will split the
image x number of times and run a thread for each.
Split up the rendering function for one that does scaling and one
that doesn't. I just don't want to deal with any kind of scaling when
actually rendering the image. The code shouldn't change much so
maintaining is going to be ok.
- Fixed scaling issues where black bars would appear if the subimage
size wasn't divisible by the scale.
- Cleaned up a bunch of arcs and other things that wasn't neccesary
any more.
|
|
|
|
|
|
|
|
|
|
- Preview quality is crude but works good enough.
- Add scaling to render function. This helps to make the preview
faster because we can use the same result for several pixels.
- You can move around the camera a bit with wasd, super basic.
- Press R to start/stop rendering the scene.
|
|
- Made the traits into supertraits so we don't have to mention Send and
Sync everywhere.
- Add methods for Vec3 that modifies the existing Vector. Can be used
to make less copies.
|
|
|
|
- All data shared between threads are now Arcs since the data is
immutable.
- Remove tokio
- Rustified main
|
|
- Created a trait for all geometry that has to implement a hit
function. Depending on if the ray hits or not it returns an option
with the color.
- Add support for multiple samples per pixel
Current issues:
- Using cooperative multitasking which isn't that
helpful in this situation since it's like running without async but
without overhead. Should switch to rayon.
- All data gets copied once per job. Will decide later what to
do (copy or put locks and share data between jobs).
|
|
|
|
Creating a bunch of futures that when completed get the buffers copied
to the screen buffer updating the screen as it gets done.
It's a bit overkill to create a future per row but it can be changed
later.
Moved hsv_to_rgb to utils. Don't even think it will be needed later.
|
|
|
