Jump to content
  • Advertisement
Sign in to follow this  
Martoon

Projecting a texture onto a model (spraypainting simulator)

This topic is 4681 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm starting on a spraypainting simulator for our Ogre-based VR simulation framework. The heart of this simulation needs to take a spray pattern texture (a fuzzy-edged circle) and project it from the spray gun onto the model being painted. I'm looking for some thoughts and pointers on the best way to go about doing this. I'd like to leverage any freely available code, etc. I'm guessing this is probably similar to realtime lightmapping (which I've never done). My initial, naive guess would be to do something like this (bad pseudocode to follow): The model to be painted has been uv mapped in an external application. The particular uv mapping doesn't matter, as long as each triangle is mapped seperately, and the triangles are not badly distorted in the uv map. When the model is initially loaded into the simulator, an "unpainted" texture is set for its material. Each time the painting sim is updated, we do the following: Using the position and orientation of the paint gun, we generate a projection transform matrix (in the local space of the model to be painted) that transforms points from the paint spray frustum to a unit cube. This lets us take the xyz of any vertex in the model, and get the corresponding uv in the paint pattern texture. This gives us a function like this: uv PaintTransform(Vertex3 modelVert) We then process the triangles in the model one at a time. For each model triangle, we create a new, corresponding triangle. This new triangle will be rendered on to the model's texture. Each vertex of this new triangle is defined as follows: newTriVert.vert.x = modelTriVert.uv.u newTriVert.vert.y = modelTriVert.uv.v newTriVert.vert.z = 0 newTriVert.uv = PaintTransform(modelTriVert.vert) We then render this new triangle on to the model’s texture, using our paint pattern texture. The dot product of the model triangle's normal with the vector to the paint gun could be used to set blending properties, since paint applies differently flat-on than it does at a glancing angle (and of course a negative dot product would exclude the triangle from painting). This technique seems like it would work, except for the glaring problem of occlusion shadowing. Triangles closer to the paint gun won't block paint from reaching triangles behind them. This one issue seems to make the whole problem significantly more complicated. I keep thinking there must be some z-buffer trick to handle this, but I haven't figured one out yet. This will be running on machines with recent gaming cards (GeForce 6 series), so if there are any buffer or shader tricks, they would most likely apply. Any tips, ideas, or pointers to other resources greatly appreciated.

Share this post


Link to post
Share on other sites
Advertisement
it seems like this could be solved simply via a technique known as projective textureing. you wanna use projective textureing in conjunction with a parallel(orthographic) projection, this would give you a cylinder type spary. if you want a cone like spray, like a real spray can, you could use a prospective projection. I could explain it but it's best explained with visual aid, so google it(projective texutreing).

if the geometry is simple enough you could even ray trace the spray particles, simply calculate the intersection and deposit the color on the corresponting texture map for that triangle.

Tim

Share this post


Link to post
Share on other sites
@timw:
Thanks for the reply. Unfortunately, standard projective texturing doesn't work for my needs. Projective texturing modifies the uv's in the model, and renders the model with an existing texture. This would only allow me to apply the spray pattern texture to the model once. I need to simulate a continuous spray, as the spray gun and model are moved. This requires me to maintain a cumulative texture for the model, and to keep adding the spray pattern texture to the model's texture in each update.

Through further research, I think that the techniques used in shadow mapping will probably solve my problem.

I had considered ray casting individual particles, but I don't think I'd get the performanced needed with the complexity of the geometry used. Although I'm still considering this, since it could yield a better simulation, and I might get decent performance if I space partitioned the model's polys in pre-processing, and used that for traversing the ray through the model.

Share this post


Link to post
Share on other sites
ya that sounds like an excillent idea it's basically kinda like projective texturing it's just you project your point being shaded onto the spray texutre and take the value of the color. I was thinking this when I suggested it, not working with the vertxes like projective texturing but the points them. really can't work with verts in this type of problem. ray tracing is actually reasonably fast for small static scenes, the problem is the acceleration structure, it needs to be built each frame, there are certian circumstances where you could move/rotate objects and not have to rebuild the acceleration strucutre, if you want to discuss dynamic acceleration structures fell free to ask. you definitly need one tho, brute force ray tracing is like, not fesable in any situation lol, unless you got like a single sphere or somthing. I like the the light mapping approach, it seems really good for the situration.

some common acceleration ray structures are

BVH-bounding volume hirerchy(very easy to impliment) not all that great for speed tho.
KD-trees- easy to impliment, very fast
grids- hard to impliment, long building time, can be fast for certian scencs
adaptive grids- hard to impliment, very long building time, VERY VERY fast for most scenes.
BSP- a weak verson of kdtree, traversial code doesn't have the simplicity of axis alligned splitting planes.(dont use it)

I recommend k-d tree personally, it's reasonably easy to impliment and fast. but if you're pressed for time, I'd consider BVH because I think thats the easiest to code. any of these tho, it's the difference between a o(n) tracing algorithm and a o(log(n))

Tim

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!