Thanks guys, your suggestions have been very useful. Fabrice: Setting bothsides to true is necessary in order to obtain valid drawTriangles, and it is what im using. And Ive thought about your second suggestion and I will definitely implement it when I can, it could reduce cpu cost dramatically for shadows. It would involve an algorithm that would decide how to fill a vertex cloud...
Rob: Your two suggestions have been implemented succesfully. Ive used the virtual face's normal to determine if it should be rendered, and while doing this, I sorted the ones passed for rendering on their distance to the camera. Its been very effective. See the new DEMO: http://www.piar.com.ar/li/away/reflections/sortingsolved/ The only problem that is left is determining in what order the 3 points are passed to the beginBitmapFill method. For this I believe I need to recognize which point is opposite to the hypotenuse of the triangle, and then somehow decide which is left to it and which is right to it... I have to pass p1, p2 and p3 in the right order in order to avoid scrambled faces. Do you know if there are any inherent conventions for this in the engine? Do you remember any part of the engine that handles anything similar to this? On Wed, Sep 3, 2008 at 7:07 AM, Rob Bateman <[EMAIL PROTECTED]> wrote: > Hey Li > > > unfortunately i can't dive straight in here due to time constraints on > other work, but i can point you in the direction of what you need > > basically your talking about two things, rear face culling and z-sorting. > both look out of whack in your reflection demo, so heres a couple of > pointers as to how you could fix the problem. > > a) face culling > > the method away3d uses for this is to return the calculated area of a > drawtriangle class (the 2d representation of a face in a view). However, > this is not going to be easy to replicate in your demo as you are drawing > directly from face to material! One way of seeing whether a face should be > culled is calculating the dot product of the face normal to the camera axis. > the face normal is easily obtained - there is a property called normal on > the face class. tranforming it to world coordinates will require a similar > set to the one you are doing in getVertexGlobalPosition, and finding the dot > product between it and the camera vector (the world z axis of the camera > object (or line of sight) is easily done with the number3d methods. if the > product is positive, the face is facing the camera and should be drawn. > otherwise it should be discarded. > > b) z-sorting > > currently this is not done at all in your render loop - basically you need > to sort the drawing order of faces so that the ones furthest from the camera > are drawn first, the next further drawn next and so on. you can get the > global position of the vertices of each face by multiplying the > scenetranform matrix of the object by the view matrix of the camera, then > calulate a zdepth value by averaging their z-values. duplicate and sort the > array based on this value, and then draw each face in the correct order. > > > sorry i can't be of more assistance right now - while the reflections you > produce look great i am in no position to take this on myself atm, so i hope > assistance in theory will be enough to point you in the right direction! > > atb > > Rob > > > > On Wed, Sep 3, 2008 at 9:16 AM, Fabrice <[EMAIL PROTECTED]> wrote: > >> Hey Li,The suggestion should work on the face issue... Set the cube to >> bothsides:true if you see the projection ok, and you have set the faces in >> right sequence order, then you are good for next step. >> >> The point I think here is that you try render faces that are not in the >> loop, at some angles, you would need to see faces not in the renderlist of >> the object. >> In other words, you want to see the mirrored dark side of the moon. >> So you will need here to write a class that is a flipped clone of the >> original mesh and use that info. This should also increase speed since the >> faces would be ready to be used at any time. They also would have a front >> property instead of back property automatically. >> >> For the shadow or fills case, may be another concept worth a try: >> Take a look at the way the outline works. So instead of drawing whole >> geometry face by face, just collect the vertexes of the hedges, project >> them, and read on Render the list you've composed to draw once the whole >> shadow shape into your source destination. This would ensure almost same >> draw speed for simple or complex objects... and since your cast image also >> is a rectangle, you even could skip some vertexes if their are not included >> in that rect. Note that I haven't read your code, so you might do it >> already. >> >> Just thinking loud here :) >> >> Fabrice >> >> On Sep 3, 2008, at 5:38 AM, Li wrote: >> >> Fabrice: Ive been working with your suggestion with no success. Tryedas >> hard as I can.... The problem seems to be reduced to finding which faces to >> draw on the reflective plane. These are not the same faces as the ones drawn >> on the "real" object. >> >> Question: Somewhere in the engine something is deciding which faces will >> be drawn. I suppose it makes this decision based on the objects position, if >> it is bothsided, etc. We need to apply this same logic to the "virtual" >> object this time, created in the reflection, and simply decide which faces >> will be drawn. Who makes this decision? And how does it create the >> appropiate DrawTriangle once it has been passed for rendering? >> >> On Tue, Sep 2, 2008 at 7:09 PM, Fabrice <[EMAIL PROTECTED]> wrote: >> >>> >>> well, its because you reverse the face and scramble it, >>> to flip a face with vertexes [a b c] , make it [ b a c] >>> >>> as about the uv's they also required to be ordered. >>> >>> uva = new UV(0, 0);//downleft >>> uvb = new UV(0, 1 );//topleft >>> uvc = new UV(1, 1);//topright >>> uvd = new UV(1, 0);//downright >>> >>> but shouldn't have to change them since you want reversed image, just >>> flip the face and you will be fine, otherwize if needed >>> flip order uvs on the exact same way as vertexes following the same >>> sequence. >>> >>> Take a look at Lathe class, many examples of combinations in there. >>> >>> //My head is about to explode!! >>> Take a break, you've done enough for today :)) >>> >>> Fab >>> >>> >>> >>> >>> >>> On Sep 2, 2008, at 11:08 PM, Li wrote: >>> >>> >>>> Ok, Im completely stuck here. My head is about to explode!! >>>> >>>> You can see the problem I have in this DEMO: >>>> http://www.piar.com.ar/li/away/reflections/theproblem/ >>>> As I tryed to explain before, im having problems when redrawing the >>>> reflected object's materials on the plane. With wirecolormaterials Im >>>> only having trouble with sorting, but with moviematerials Im also >>>> having trouble with the orientation of the vertices in the >>>> beginbitmapfill method. >>>> >>>> Ive made a big effort to make the source organized and have lots of >>>> comments, so, here it is: >>>> http://www.piar.com.ar/li/away/reflections/theproblem/AdvancedReflections.zip >>>> >>>> I believe that if someone familiar enough with the engine's core grabs >>>> this, the problem would be resolved easily and quickly... A little >>>> help and we're done! >>>> >>>> On Sep 2, 3:30 pm, Li <[EMAIL PROTECTED]> wrote: >>>> >>>>> Thanks Peter, and everyone else for the positive replyes... >>>>> >>>>> Here it is with an jpeg as bumpmap: >>>>> http://www.piar.com.ar/li/away/reflections/bumpwithimage/ >>>>> >>>>> On Tue, Sep 2, 2008 at 3:07 PM, Rob Bateman <[EMAIL PROTECTED]> >>>>> wrote: >>>>> >>>>>> very cool! love it. >>>>>> >>>>> >>>>> Rob >>>>>> >>>>> >>>>> On Tue, Sep 2, 2008 at 6:56 PM, Jensa <[EMAIL PROTECTED]> wrote: >>>>>> >>>>> >>>>> Awesome job Li! Keep at it! >>>>>>> >>>>>> >>>>> J >>>>>>> >>>>>> >>>>> -- >>>>>> Rob Bateman >>>>>> Flash Development & Consultancy >>>>>> >>>>> >>>>> [EMAIL PROTECTED] >>>>>> www.infiniteturtles.co.uk >>>>>> www.away3d.com >>>>>> >>>>> >>> >> >> > > > -- > Rob Bateman > Flash Development & Consultancy > > [EMAIL PROTECTED] > www.infiniteturtles.co.uk > www.away3d.com >
