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.

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.