Hey Fabrice, I noticed the proper flip issue and fixed it. About the rest of your commentaries I totally agree and will consider them seriously. Unfortunately Im gonna be a lot more busy these days so I wont be able to make progress on this for a while. Anyway, I take it as a good chance to slow down and start up a fresh copy of these classes, considering all the issues that came up during experimentation. So, I ask you and (anyone else interested) to drop any helpful commentaries here while I develop it. With a bit of patience, this should be a cool thing to have available in a few days...
Cheers! On Thu, Sep 4, 2008 at 4:56 AM, Fabrice <[EMAIL PROTECTED]> wrote: > My suggestion to set the bothsides to true is not to be used in the final > version, it's just a way help you to build it up and solve each problems one > at a time.Right now you have more issues, one of them was a proper flip of > the faces and set the uv's in right sequence. See it as a debug. When the > bothsides info would be correctly displayed, then you can go for step two, > use the back faces only. > Btw, using a grid like texture with colors, like a TV test image is also a > faster way to see what's going wrong. > > As about the hedges vertexes selection, the code is in there already. > Indeed an algo to fill a shape from points will be required. > > Fabrice > > On Sep 3, 2008, at 6:16 PM, Li wrote: > > 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 >> > > >
