Tattoo Projection Paint Demo
Community Forums/Developer Stations/Tattoo Projection Paint Demo
| ||
| Hi all, Still working on Tattoo's projection painting. I did a little video (<1 Mb) which shows it in action. Download If you don't have the CODEC already, it is included in the zip. Let me know what you think so far. BTW: I'm using a DISCO mapped model with a low resolution (disperate Atlas Mapped with some UVs reversed etc.) texture to show how seams are coped with!)   |
| ||
| Wohooo :) Looks great! This has been missing from Tattoo, for too long. Why is the paint only updated at the end of the sequence? Can't it be updated in realtime? |
| ||
| Do you mean the reprojection at the end of the video? Unfortunately it take a fair bit of power to reproject the image. Even BodyPaint2 and DeepPaint3D take several seconds to reproject when coming out of projection mode. I'm also limited in speed since ReadPixelFast and WritePixelFast are still relatively slow for large images. If you mean "Why does each *stroke* appear after it finishes", this is just a 5 fps video, in actual fact the screen refresh is as normal. |
| ||
| Even BodyPaint2 and DeepPaint3D take several seconds to reproject when coming out of projection mode. Yup... we need faster HW! :) |
| ||
| This is the problem really. If you take away the 1x scan of the viewport into the Texture using ReadPixel and WritePixel, I can reproject at something like 10-30 Frames Per Second. The couple of seconds delay comes from the initial compare of two textures (using the ReadPixel stuff) to look for changes. |
| ||
| I was thinking of making some other changes to the next release. I was thnking of doing away with the 'Solid Brush' and making the first entry on the brush list, a multi purpose configurable airbrush type with dynamic opacity falloff etc. |
| ||
| This looks GREAT! Lee, I can`t wait to test drive it :) In response to your last note, I agree with losing the solid brush in favour of the multi purpose airbrush, it makes sense. Keep up the great work, Jason. |
| ||
| Oyy. pls dont take away the only ool i use hehe. the Solidbrush hehe :) |
| ||
| LOL! :) |
| ||
| That is very cool man! Nice to see it in action, as i wasn't 100% sure what you meant. :) Can't wait for the next release :D |
| ||
| Nice work! DP3D & BP3D watch out :P |
| ||
| @Lee u need a faster read /writepixelfast ? would glad to help |
| ||
| Hi PANNO, A lot of Pixel type things are quite slow in blitz. The WritePixelFast stuff and also the CopyRect command for textures and buffers. If there was a faster way to do these (which would work also on every target PC) that would be very useful indeed! For example RenderWorld CopyRect 150,24,vpw,vph,0,0,BackBuffer(),TextureBuffer(fsc) CopyRect 0,0,vpw,vph,0,0,TextureBuffer(protex),TextureBuffer(fsc3) For suy = 0 To vph For sux = 0 To vpw AX = ReadPixelFast(sux,suy,TBFSC) BX = ReadPixelFast(sux,suy,TBFSC3) If AX<>BX Then WritePixelFast sux,suy,bx,TBFSC Else WritePixelFast sux,suy,bx And $00FFFFFF,TBFSC EndIf Next Next takes up to two seconds on my reasonably powerful PC! |
| ||
| ok i will help ! email later ! |
| ||
| email4u |
| ||
| Thanks. I'll take a look :) |
| ||
| email |
| ||
| @lee memoryswap is to slow to make a fast dll the texturetest (your code) need 60 ms here (only the function) BUT the memory swapping need 1692 ms In this case i have more ms as bb function'S i must swapp the texture 3 times ,grrr if i use memory directly in the dll it's also slower grrrrrr sorry i cant help u in this case Anyone knows a fast way to access imagebuffer ? if i use asm it's not fast if i use rtlmovememory also get bytes from a bb application is slow ! cld ! mov esi, src ; bb memory ! mov edi, dst ; dll memory ! mov ecx, ln ;1024*1024*4 ! shr ecx, 2 ! rep movsd ! mov ecx, ln ! and ecx, 3 ! rep movsb this is the fastet memorymove that i know but i get over 1000 ms if src a adress in the bb application is it windows ? i dont know ? hm need i a call for windows or dx that i will use the memory Mr. Sibly u know why ? |
| ||
| It's been interesting to see how some things can go fast and others seem to be locked down. Perhaps it is in the nature of the Direct 3D architecture involved. Mark doesn't strike me as someone who would leave it as slow if there wasn't a good reason. All I was hoping for in this case, was that customising the movement routine for a specific type of movement (such as copying an entire texture at a time) or accessing a set of pixels where you already know the format. Could be sped up. Your efforts have been appreciated, even if they didn't go as far as you would have liked :) |
| ||
| For suy = 0 To vph For sux = 0 To vpw AX = ReadPixelFast(sux,suy,TBFSC) BX = ReadPixelFast(sux,suy,TBFSC3) If AX<>BX Then WritePixelFast sux,suy,bx,TBFSC Else WritePixelFast sux,suy,bx And $00FFFFFF,TBFSC EndIf Next Next this need 69 ms here as a dll function but the images swapping is not real fast ! for the next update i wish a copymemory to bank or copyrect to bank for b3d added later will mutex or semaphore help me or iam on the wrong way ? edited later forget mutex He Marc it'S Cristmas ;) |
| ||
| the reason why is when you eighter write or read, assembler is a lot faster than when you do both at the "same time". Instruction cache works much better in that case. So maybe you should push and pop blocks instead of countless single 32 Bit i/o accesses ? |
| ||
| no jfk not the goal |
| ||
| at least this happened when I wrote a 3d engine in FASM. I tried to read the pixel colors before drawing to them, but this reduced the speed by about 4 times. |
   |