Trying to fix my weights…
Cant figure out why his fingers are broken 
matrix-drift ?
Did a quick search. From what I can see that’s because of rotation and scale being stored in the same components of a 4x4 matrix?
However, I don’t have any scaling in my vertex skinning
I implemented a Ray Caster in addition to my Path Tracer in my 3D-engine. They’re both realtime.
Ray Caster:
http://www.dayflower.org/Dayflower-Engine-33.png
Path Tracer:
If it’s realtime, post a gif! 
I have tried to find a program to record it, but none of them have worked for me. But I can tell you the Path Tracer isn’t fast. Some scenes, but not the one shown here, do have an FPS of around 100 or so, although the image will still be grainy and converge over time. The image of the Path Tracer took quite a long time to render (maybe an hour, I’m not sure).
Edit: More images can be found at: http://www.dayflower.org/
Have you tried sharex?
Has a decent gif recorder, and uploads straight to imgur as a gif/gifv
Thanks for that tip! I did install it and have to learn it. But then I can do it. It looks great though.
Edit: I’ve now uploaded a video to YouTube: https://www.youtube.com/watch?v=EZUn-aJ-ocs&feature=youtu.beMmB9b5njVbA
[quote=“theagentd,post:4629,topic:49634”]
That looks very good. Is this using a port of Mikkelsen’s tangent space generator, or something else?
[quote=“boxsmith,post:4649,topic:49634”]
Indeed, but after staring at mikktspace.h for a couple of weeks I just said “fuck it” and wrote a Blender plugin and exported it all from Blender instead (Blender uses it too).
Most of two days spent on a very elusive bug. Due to the intermittent nature and not a whole lot of confidence in my multi-threading chops, spent a lot of time checking things like possible race conditions, lack of atomic operations (where I thought they shouldn’t really be required), deep vs shallow copy errors, that sort of thing. For the first time, also, employed a debugging technique I hadn’t used before: catching and re-throwing the error down the call stack, thus allowing reportage on variable states at several levels.
It turns out though, that the problem was due to simple accumulation of arithmetic error. I discovered that if you add a float value that is in the E-6 range 400,000 times (via +=) or so, it can cough up a pretty sizable error compared to just doing the multiplication.
I don’t know how to describe it any better without going into details no one want to read about.
Result: envelope operations on the synths are now being done via doubles rather than floats. I was afraid I’d break everything when I converted to doubles, but it only took about 20 minutes, once the changes were made, to fix the downstream errors that were generated. Am back to a pristine Eclipse: 0 Items in the “Problems” tab.
The “flibber” effect on the Allenspace generator is now much more like the original. Intermixing via selecting tracks at random has a much more satisfying aural glitchiness than iterating through the tracks, even when the time spent per track was also subject to variation.
We finally successed to port the original openvr sample to jogl, after we wrote the openvr binding
If anyone is interested in writing an lwjgl version, you are welcome to contribute 
@philfrei, I’m liking the Allenspace Generator! It’s like a Geiger counter on acid.
It would be a good background track for a science fiction / hacker / creepy aliens kind of game.
Edit: But what does the “Release” button do? I’m scared to press it. I’m also scared to not press it.
I upgraded my Blender plugin a bit. It can now export the skeleton/bindpose of a model, and vertices with normals, tangents, UVs and bone bindings.
I worked on a random tree generator (you actually slowly see the tree grow from nothing) :
http://img4.hostingpics.net/pics/526240trees.png
It’s absolutely useless but provides good result sometimes as shown in the image but also provides some absurdities.
Thanks!
I love your description–it’s the best I’ve heard yet.
I think it would be neat to see the tone-cluster sound data sent to some sort of color synthesizer or graphic algorithm. But yes, I’m thinking it would be a component of a deep-space (deep inner space) stealth sort of scenario.
The “Start” and “Release” buttons refer to the auto-generation of tone clusters. “Release” just prevents any new sounds from occurring. Existing sounds will play out. To be relabeled.
When a “real” gui gets developed, it will be important to clarify what pertains to the “next” tone cluster that is going to be produced (most of the sliders) and what pertains to present-time controls like the flibber button and the bottom volume control. (Should also have a way to save/load settings and to export wav files, as well as better fitting slider equations than linear in certain instances.)
These are the longest envelope durations I’ve worked with, with sounds set up to crescendo/descrescendo for as long as a minute. But that is also part of the design, to have a slow evolution. However, it does mean that you have to wait for the next cluster, which can take a while, to hear what the new settings are producing.
I’m thinking of adding an echo control, as that worked very well to give the theremin extra depth. A reverb would be preferable but I’m not ready to tackle that challenge yet.
Could you post a gif? :
Those are the ones i could make though they’re not the best.
http://i.giphy.com/LOQOHaKtSYohy.gif
http://i.giphy.com/nnEEwBJ0kLu.gif
If you really are curious, that’s the little program i use to see and generate the trees download it (the .jar) .
Quick explanation of the interface for the curious : evolution makes the tree properties evolve each time it grows : when age reaches 100% the current tree properties are kept and mutates only if evolution is checked, speed - or speed + double or divide by 2 the speed, restart recreate a randm tree from scratch and reload makes the current reaches age 100%
Maybe you could try to make the trees look slightly better by not allowing branches to grow oriented towards the ground? Also maybe you should only allow branches to grow in a π/2 — 3π/2 range commencing at the angle of the parent branch?
So basically what I’m saying is that the angle the branch grows to should be in the range [ max(π , angle_of_parent_branch - π/2) ; max(π, angle_of_parent_branch + π/2) ]
I don’t know what it’ll look like (or if these changes are compatible with the program you wrote, I didn’t take the time to take a look at your source code) but I guess you should try
J0