next »

[Neowedge]

This Christmas I got some free days and I used it for learning how to deploy a Lumen WS in Amazon Web Services with SSL. I got it and now I feel unstoppable

[oahda]

Hooray, Neowedge! I'm using my vacation similarly. ε:

Today I'm happy about having managed to understand and program shadow mapping from scratch in OpenGL for the first time!



It's the simplest version, so it can look a lot nicer, but it's a really cool start!

[InfiniteStateMachine]

I finally naturally understand the terms fold and unfold enough to actually use them frequently

It probably took me like 2 years to really get it but now I understand what all the fuss is about higher order functions.

[JWki]

Hooray, Neowedge! I'm using my vacation similarly. ε:

Today I'm happy about having managed to understand and program shadow mapping from scratch in OpenGL for the first time!



It's the simplest version, so it can look a lot nicer, but it's a really cool start!

Shadow mapping always adds a lot even when it's crappy.
Nice to see how you're coming along with OpenGL, makes me really itchy to do some actual 3D graphics programming again. Unfortunately I have to deal with HTML at the moment.

[oahda]

Aww. Hope you'll find the time eventually!

Today I've been messing around with ImGui and the addons ImGuizmo (3D manipulation gizmos) and ImGuiDock (providing the resizable docks that make up my interface). I had to hack around in ImGuizmo quite a bit to get it to obey me, and a little bit in ImGuiDock as well, but I've finally got what can turn into a neat editor for the engine up and running. e:

[JWki]

Uh I didn't know ImGuizmo, looks nice!
Also fuck it gonna do some graphics programming now. If I fail my thesis, you're to blame.

[oahda]

 

[Neowedge]

Hooray, Neowedge! I'm using my vacation similarly. ε:

Today I'm happy about having managed to understand and program shadow mapping from scratch in OpenGL for the first time!



It's the simplest version, so it can look a lot nicer, but it's a really cool start!

Wow! It looks great!


Good luck with HTML, JWki

[JWki]

Better to wish me good sanity because I feel I'm losing that more.

Anyways pretty happy because struggling with HTML is only one of the horrible things that I have to deal with for my thesis, the other one being how to make all the fancy native stuff I know how to do work in a browser. Not having file system access was more difficult for me than I thought it would be but also gave me an opportunity to come up with some nice solutions to problems.
I too use dear imgui for parts of the interface, and it was a pain not having the built in layout serialization it provides so I made some changes to it that allow registering callbacks for serialization and deserialization so now my frontend code simply uses a cookie to read and write interface layout.
Also making HTML forms other than the emscripten canvas receive keyboard input events was a bit iffy.
So yeah happy that I solved all that in a somewhat timely manner.



EDIT: Whoops that's a bit large.

[oahda]

Max width is 885, so this does the trick:

Code:

[img width=885]…[/img]

Looks cool! Emscripten is a lot of fun. Bit of a Frankenstein creation with some of the interface in HTML and some in cross-compiled C(++)! p: Are you doing that in order to be able to tie it into your thesis somehow, or is it just for fun any way? Going to be using it for anything particular?


My interface is coming along too! I've implemented full docking functionality into ImGuiDock, but I then noticed resizing views was buggy, and trying to fix it wasn't so simple based on the weird way the views and subviews have been implemented by the original author, so I'm going to rewrite the entire foundation of it as well, really leaving nothing of the original library's code in the end, so I guess it'll be my own work from scratch after all, heh.

[JWki]

Thanks for the tip I hate using forum tags never got around understanding which ones work where and how.

Emscripten can also be pretty annyoing in some ways but it's working out alright.
This IS my thesis - they need a tool to debug their gcode better at the chair I'm doing the thesis at so that's what I'm giving them. It's web based because the idea stemmed from writing a plug in for an existing web based tool (octoprint) that then mutated into going from scratch.

On imgui docking, I'm also going to write something for that at some point probably because it really is a nice feature to have and the existing implementations can all be improved on and I like writing stuff from scratch anyways.

[oahda]

This IS my thesis

Ah! Well, there you go. Now you can combine the things you need to do with the things you want to do, I guess? p;

On imgui docking, I'm also going to write something for that at some point probably because it really is a nice feature to have and the existing implementations can all be improved on and I like writing stuff from scratch anyways.

Well, I'll probably be posting my code somewhere once my rewrite is done too, so if you want to use or look at it after that, feel free. c: My windowing stuff for the docks is based on callbacks that are registered with the dockspace object in order to tell it how to create windows and so on, so it's completely agnostic of the underlying windowing system and the only dependency is, well, ImGui, so it's not hardcoded for SDL or anything.

[gimymblert]

Hooray, Neowedge! I'm using my vacation similarly. ε:

Today I'm happy about having managed to understand and program shadow mapping from scratch in OpenGL for the first time!



It's the simplest version, so it can look a lot nicer, but it's a really cool start!

TRY THAT:
Instead of just doing a test to see if a fragment is below the depth sample,
- when below, compute the distance from the fragment to the depth sample
- use the distance as a weighted attenuation to the light intensity (possibly per material type)
- apply light intensity to the fragment.
- look at the object from behind relative to the light direction.
- ? ? ?
- PROFIT!

[oahda]

Sounds good! I haven't touched the shadows since I posted that since I moved on to playing around with ImGui, but will experiment with that when I get back to 'em. ε: Will also try implementing cascaded shadow maps eventually~

[oahda]

I'm going to bed, but have made some good progress on programming my own docks from scratch today! e:



The last thing I added just now was the resize bars (using ImGui software cursor for quick testing, but will make the system register callbacks for showing native cursors). They don't work yet, but they do appear where and how they should. c:

But of course the most work has gone into designing the underlying workings of docks and subdocks and so on. It got more complicated than I had imagined, but I think it works. Will put it properly to the test once I've got undocking working again and can try to place docks in new places.

[JWki]

This IS my thesis

Ah! Well, there you go. Now you can combine the things you need to do with the things you want to do, I guess? p;

On imgui docking, I'm also going to write something for that at some point probably because it really is a nice feature to have and the existing implementations can all be improved on and I like writing stuff from scratch anyways.

Well, I'll probably be posting my code somewhere once my rewrite is done too, so if you want to use or look at it after that, feel free. c: My windowing stuff for the docks is based on callbacks that are registered with the dockspace object in order to tell it how to create windows and so on, so it's completely agnostic of the underlying windowing system and the only dependency is, well, ImGui, so it's not hardcoded for SDL or anything.

Well kinda not really digging the subject matter too much but that's fine.

Oh I'll be looking at your code, the callback system sounds pretty smart actually.

[oahda]

Here's someone else's open source solution if you want to have a look at it:

https://github.com/thennequin/ImWindow

Haven't dug into it, so I don't know how feature-complete or bug-free it is, or how dependent it is on a particular external windowing system, but leaving this here in case you're interested. C:

[surt]

Had abandoned project due to bug which I was sure was due to some compute shader memory barrier weirdness, only to look at it again and discover I was just losing my buffer binding!

[oahda]

It generally turns out to be one's own fault in the end, doesn't it? c;


I think I may be done with dock (re)sizing, including minimum size limits (200 used here) and refitting docks to make sure they cover the whole canvas perfectly. I think I've got it! Will bugtest some more tomorrow, but that's it for today. ε:

[JWki]

I'm a happy little programmer because I fixed my job system. The task queue implementation was broken because I wasn't using locks correctly, leading to sometimes some thread trying to unlock a mutex that had been locked on another thread.
It's really not a fancy implementation (it's not lock-free, not even wait-free I think) and not the fastest in the worst case but I won't have too many tasks at the same time, I just want the parallelism out of it, not necessarily optimal performance, the load will never get very high.

Also it took me about thirty seconds to figure out why my event queue (I do use lots of queues) was broken as well - unlike my task queue, which simply uses std::deque because I don't care about performance and all the elements in it will always have the same size, my event queue uses a ring buffer because event data can have arbitary size (and std::deque really should be a ringbuffer not the horrible thing it is) and I had a tiny typo leading to the write offset not wrapping around the buffer so after like 64 megabytes of written event data I'd overflow the buffer.
On the upside, I know now how many events it'd take to actually fill the buffer and that I probably won't need a bigger buffer anytime soon.

Did I mention I like queues?