Title: Camera maths - Help please! Post by: Patryk Kizny on July 23, 2015, 01:38:45 PM I've gone quite far, but I come to the point where I have no idea why something that should work in practice doesn't.
Goal: External handheld camera composited with Fragmentarium-rendered fractals. Process: - Shoot - Track in Boujou - Export camera as TXT (3x3 camera rotation matrix + vec3 position data) - Put this as a const array in Frag (separate mat3 rotation array and vec3 pos array) - Access the array rows based on frame numbers (in fact I used a uniform float slider animated linearly across time to work around imperfect frames addressing when based on time*framerate expression) - Set fragmentarium camera accordingly - Render out - composite (in Premiere or any other app) This is what I got and I am wrapping my head around for the last 3 days to learn why the camera from fragmentarium won't match the original. https://vimeo.com/134293286 Maths can be either good or bad. It can be halfway good, right? You can't blame it also on insufficient data resolutions as all positions have 10 or 12 digits precision. Here's what I know:
My coordinate system is right-handed, Z pointing upwards and Y pointing forward, X pointing to the right. Here's how camera data is structured. Sample of data from Boujou with headers (just to give you understanding of how it's described): Code: # boujou export: text This is converted to fragestible data: Code: const mat3 iCamDataDir[250] = mat3[250]( Here's how I retrieve camera positions (this is coming from 3D.frag and sits within #vertex section) Not sure why, but I needed to *(-1) the up vector to match (can this be wrong?) Code: // This is the file with coordinates and orientations http://www.gamedev.net/topic/666236-converting-axis-angles-forward-right-up-to-euler/#entry5213778 Further within #vertex main() I have: iCamWeight is just a float to enable and mixin my imported camera positions. It is set to 1. Adding normalize() to Dir/Up/Forward won't change anything as I belive matrix data is already normalized. Code: vec3 Upn; That's pretty much it. What's wrong here? I attach frags. To make get it up and running select Default, apply, then select range preset and apply. Scrubbing in timeline animation mode should move the camera. To test it against the source one needs to render and composite externally (I did manage to pull in single-frame background, but did not get Frag to update it per frame. I'll be happy to share backplates if anyone needs that. But hopefully you can help by looking at maths and the code solely with a fresh eye. T H A N K Y O U Title: Re: Camera maths - Help please! Post by: kram1032 on July 23, 2015, 02:47:00 PM Hmm. Well, I'm no expert at this at all. But did you give Blender a try for this? Their camera tracking is becoming better almost by the minute.
Though I'm not sure whether it'll serve you with compositing in the same way After Effects would, so Iunno. Title: Re: Camera maths - Help please! Post by: Patryk Kizny on July 23, 2015, 03:01:50 PM Looks like I spotted a flaw. The matrix order coming from boujou is by row and I assumed and declared matrix by column.
Fixed. Second thing - should I be doing: Code: vec3 getCameraFw(){or Code: vec3 getCameraFw(){Title: Re: Camera maths - Help please! Post by: cKleinhuis on July 23, 2015, 03:16:26 PM way cool, you create the camera angle based upon incoming webcam ? niceeeeeeeeeeeeeeeeeee!
Title: Re: Camera maths - Help please! Post by: Patryk Kizny on July 23, 2015, 03:20:10 PM way cool, you create the camera angle based upon incoming webcam ? niceeeeeeeeeeeeeeeeeee! It's a DSLR camera tracked in boujou. But yes. Way cool, but does not want to work as I expected. I feel dumb whenever I have to use Maths. Title: Re: Camera maths - Help please! Post by: 3dickulus on July 23, 2015, 03:33:01 PM wow, embedding a fractal object in the studio floor, don't trip on that ;) seriously O0 you've made some great progress, I can't wait to see what you come up with for the demo reel :o
I think this is a first for Fragmentarium! I haven't seen anything quite like this. KEEP GOING!!! you're results so far are awesome. It took me a looong time for me to get path occlusion working, just keep at it and the secrets will reveal themselves :D sometimes you have to put it down and let the observations percolate in your head for a while. the path resolution in the live video I think will be more detailed than the path in Fragmentarium, need more samples to feed into Fragmentarium or smoother motion wrt the hand held cam? edit:just a thought, if you make iCamDataPos a slider in Fragmentarium it will become magically available to the javascript engine allowing you to set it there, you will also be able to monitor values in the GUI as they transition from one pos to the next ;) (put it in the [Camera] group) Title: Re: Camera maths - Help please! Post by: Patryk Kizny on July 23, 2015, 06:57:58 PM Guys, thank you for the encouragement.
Anyone can help solving the thing? Looks like the matrix order was right anyways, because when I reveres it (row-col swap) I wasn't able to get any results that would make sense. And still it does not work as expected. Can one look into my camera maths? Title: Re: Camera maths - Help please! Post by: claude on July 23, 2015, 08:36:14 PM I tried the frags, but my driver doesn't like it (NVIDIA GTX550Ti):
Code: Internal error: assembly compile error for fragment shader at offset 407518: Looking at the video it feels like the rotation is fine, but the translation is messed up (it looks a bit stuck to the camera, rather than stuck to the floor). Could be a lot of things (real vs virtual camera field of view, real vs virtual scene scale), but to narrow it down I suggest making a virtual scene with a simple wireframe cuboid that should line up exactly with the green crosses. Title: Re: Camera maths - Help please! Post by: eiffie on July 23, 2015, 11:19:11 PM Unfortunately I can't view the video to see if this is correct but the export says the rotation is applied before translation. If that is true then you might have to rotate the position data back.
Title: Re: Camera maths - Help please! Post by: Patryk Kizny on July 24, 2015, 01:52:24 PM Guys! We nailed it.
There were a couple of things that made a mismatch. I don't know the reason yet, but already got a solution. This is very weird, but in order to make things match I needed to: 1) Scale the scene by the factor of 2.0 2) The camera FOV that I added to renderer for some reason operates on vertical film dimension instead of horizontal. I'll have to look into that. And to figure it out I needed to follow Claude's suggestion and added a floor tile. Then it was apparent I have a perspective mismatch. Now there's a lot of coding optimization because I believe the amount of stuff I added to #vertex could be an overkill. Made my day. Title: Re: Camera maths - Help please! Post by: Patryk Kizny on July 24, 2015, 02:03:50 PM https://vimeo.com/134401949
Title: Re: Camera maths - Help please! Post by: cKleinhuis on July 24, 2015, 02:20:48 PM :thumbsup1: :thumbsup1: :thumbsup1:
Title: Re: Camera maths - Help please! Post by: Syntopia on July 25, 2015, 12:01:47 AM Very nice! You could also use an transparent ground plane (such that shadows can be properly composited on your video).
You could also capture a panoramic view of your office, and do IBL lighting and reflections, this could be very convincing: http://blog.hvidtfeldts.net/index.php/2012/10/image-based-lighting/ (these HDR panoramas are not easy to make though). Title: Re: Camera maths - Help please! Post by: Patryk Kizny on July 25, 2015, 02:23:38 AM Haha, you read my mind. Both things are on my todo list.
But in order to implement that I need to restructure the raytracer seriously (in the middle of that). Current structure has #post section applied very much on top of the pipeline, so it does not allow to exclude background from processing etc… I'm implementing a bit more complex struct to be passed upwards the pipeline, that essentially includes: Struct SColor { vec3 RGB; vec3 Tag; float Z; //depth float A; //alpha bool DoPost; } This essentially allows me to decide which parts of the image coming from trace() and color() will be postprocessed. Trace also color-tags scene content and adds VFX-like scaled Z-depth. Entire #post section is moved from Buffershader to 3D.frag Finally I already also added flat style bitmap background. I already implemented most of this and it seems to work, but I broke something in the middle because it stopped accumulating subframes. Bummer. Need to spot it now and then it should be fine. Then I head on to implement matte object (that will receive shadows) and IBL. Title: Re: Camera maths - Help please! Post by: 3dickulus on July 25, 2015, 05:05:42 AM very impressive! nicely done! :beer: :beer: :beer: |