FRAGMENTARIUM - My first video Test

[vinz]

Hi 3Dickulus.

I've taken some time to build another test animation, i had some hard time to encode it smoothly ! but everything seems running perfectly here with your lastest code.
here the link if you want to check.

This one is based on the regular de-raytracer, i've used the same keyframe as previously with the bulb.
i need to re-check on my side with eiffie gi render ...

http://ge.tt/80Yqi7l?c

[3dickulus]

wow that's quite the bulb! anim looks nice and smooth great!

I'm curious about how the interface feels compared to the original?

[vinz]

Hahaha! this is just a draft test nothing nice in that :p except the smooth camera move  

To Answer to your question here a screenshot of the win gui, As you can see the sliders for me are an issue. they are very small and difficult to select.

EDIT: I think these changes come from the move to Qt 4.8.5, because i've the same result by building with the current fragmentarium sources. is there a way to change that?
-anyway, it's not a big deal right now

[cKleinhuis]

one question, since i can not test it out, if i understand correctly, right now just camera pathes are animatable?!
what about ANY parameter in a keyframe to be interpolated?

[vinz]

Yes you're right ! for now only camera path !

i've asked also for dof and focus, the plan there :
http://www.fractalforums.com/fragmentarium/cat-mull-rom-spline-paths-cameraparameter-keyframes/msg63315/#msg63315

[vinz]

HAhahahahahah ! i've solved my issue ... dunno why all windows styles have the same problem.
i've found the way to force a style  

by adding these lines in main.cpp

Code:

#include <QWindowsStyle>
#include < QCleanlooksStyle>

Code:

QApplication::setStyle(new  QCleanlooksStyle);

 

hahha now i've usable workspace...

[cKleinhuis]

hmm, nice, as far as i see there are now 3 dudes developing the program, be sure to work in the repository ))
to make it later available

[3dickulus]

that looks much better! Qt is nice that way, the style code is very hackable as you may have noticed from the items on my web site.

[vinz]

hmm, nice, as far as i see there are now 3 dudes developing the program, be sure to work in the repository ))
to make it later available

hahah yes but i'm not a programmer 

yes 3dickulus i've seen that nice work by the way

[3dickulus]

hmm, nice, as far as i see there are now 3 dudes developing the program, be sure to work in the repository ))
to make it later available

my github page says only 2 contributors (me and he), Syntopias github page says 1 ... who's the third? have they forked/branched? got a link?

I will only put code into the repository when I have a working prototype, sometimes that will be a brute force implementation of an idea to be cleaned up later but it has to at least function and be useable, the fork I started has a couple of small bugs but it works and hasn't crashed my machine or segfaulted on me and with input from Vinz I'm pretty sure it won't crash a windows box, btw, tnx Vinz

I have visible paths but they're kinda useless until I can get depth cues working and then, well, you are going to want to point and click to add control points and twiddle them around with the mouse to edit them and... well I'm not sure I'll get that far... in time, we'll see

can anyone demonstrate how to get GLSL raytraced object surface coords into the glDepthBuffer ? I'm on the right track but I think it's a bit more complicated than mapping the "dist" variable in the DErt to gl_FragDepth

[eiffie]

I would just put the depth in the buffer and recalculate the coords from the camera position and ray direction. (Not really sure how you are using the info?)

[3dickulus]

I would like to have the GLSL object occlude the spline paths so...

render object, store depth buffer values, render splines... sounds simple enough

the depth buffer has a range of 0.0 - 1.0 while near/far is 0.001 - 100.0 (probably excessive but can be adjusted)
linear Z buffer = ( Z - nearZ ) / ( farZ - nearZ ) and non-linear Z buffer = ( 1/Z - 1/nearZ ) / ( 1/farZ - 1/nearZ )
OGL is non-linear I think ie:more resolution when near less when far

need to adjust the hit.xyz? values in a hybrid sort of way with xy as screen coords and z as depth buffer value?
or the distance/length requires transform and scale from eye to screen matrix ?

I'm not really sure about the GLSL side of things, input would be appreciated.

[3dickulus]

HAhahahahahah ! i've solved my issue ... dunno why all windows styles have the same problem.
i've found the way to force a style  

by adding these lines in main.cpp

Code:

#include <QWindowsStyle>
#include < QCleanlooksStyle>

Code:

QApplication::setStyle(new  QCleanlooksStyle);

 

hahha now i've usable workspace...

just played around with that, great idea!, should be an option in preferences
you don't really need the include code (on linux) just one line

Code:

QApplication::setStyle("cleanlooks");

is enough to do it