Thanks Fabrice. Today I use Segments embedded in Mesh. I tried LineSegment but it was way more expensive than the other approach.
Are you saying LineSegment will be the preferred approach in Away3D 4, or just that Segments in Meshes are not available yet? I will go back and look at your LineSegment posts. Best, BW On Wed, Mar 30, 2011 at 1:10 AM, Fabrice3D <[email protected]> wrote: > If you use LineSegment it should cost very little. > > a little status on this: > - its unfinished > - lines are now not rendering propperly on OGL side, its a known issue by > Adobe > - The program we use now is wrong, and we have a faulty matrix, I'm waiting > on David's return from USA for this. > > aside the rendering which is not optimal for now > the implementation is also unfinished > right now, only 80% is done, > basically you have now a system offering two entries, one is what the > WireFrameGrid is doing, and one is the LineSegment > the system will change and settle once we have 2 missing features: > CurveSegment and objectbase lines, offering to transform lines on a mesh if > this object has for instance an outline, debug on or showNormals on etc... > > the system right now is basically composed of a manager, filling a single > buffer, each segment instance is simply a ref into the buffer. > We can have multiple line colors in this buffer which is great, unlike > entities such as mesh where each submesh has a dedicated resource buffer per > material > we do store 14 entries in buffer per line segment, and it will go to 17 per > line once curvesegemnt is added. > the main change is that the system will soon have separated buffers or an > added ref entry point for the transforms. > to give you an example, if you now would make two cubes and lets say the > primitivebase would have the debug implemented, after contruct both cubes > would be displayed with their > lines, but right now, if you would scale or move one of the cube, the cube > would move, not the debug lines. Therefor, we need to add/extend the manager > to allow dedicated matrixes per objects, yet > keep the buffers as compact as possible. We also want to keep the ease > comparable to 3.6 where you do not need a complex code just to generate > lines. Right now you need to import and declare the manager > but eventually this will be handled by the core for you. > > using LineSegment now, you have already quite a few possibilities, and the > few tests I did in that regard shows you can have an unsane amount of > lines, > way above what you would consider wize to show on a screen, running at a > steady 60/60. > > I have posted already a few examples on how to use the actual classes. Let > me know if you missed them. > > I hope this gives you a better idea of the actual system. > > Fabrice > > > On Mar 30, 2011, at 6:57 AM, Bob Warfield wrote: > > There are some aspects of Away3D that I don't see how molehill can help. > > > I have a peculiar app in that I mostly build meshs that are all segments > and no faces, but I have tons of segments. These are used to create > wireframes of CAD/CAM objects for machining on CNC machines. For my app, > the cost of building those wireframes seems to be very high relative to the > cost of rendering them. I see how Molehill will make rendering much faster, > but I am less clear on how it reduces the cost to build the data structures > that are going to be rendered. If there are silver bullets that improve > that, wonderful. If not, eventually I'm going to want to figure out how to > make creating the data structures a lot faster. > > I need to take a look at some of the importers and see if they have some > tricks I haven't figured out yet. But, to the Away3D team, I hope you're > thinking about this end too. After all, with the power to render more > complex scenes comes the desire to build more complex scenes and faster! > > Cheers, > > BW > > On Tue, Mar 29, 2011 at 9:52 PM, Michael Iv <[email protected]> wrote: > >> Wow man are you trying to say that Away framework slows down thinkgs so >> much? Interesting what the team can say about your findings.I still did not >> perform any speed tests with Away4 but I wrote some "pure" Molehill based >> app containing around 130000 triangles across 100 different objects in the >> state of constant transformation (rotation,scaling and spherical movement) >> and my FPS even didn't blink! However I should admit that I had no lights >> and no texture mapping,only vertex colored shaders/ >> >> >> On Wed, Mar 30, 2011 at 1:29 AM, Dave <[email protected]> wrote: >> >>> I wanted to share some very basic performance numbers and get the team's >>> take on these. >>> >>> First, some basic info: >>> >>> - I have wmode=direct on (let's get that out of the way) >>> - We have a 3952 poly character model. We're using 8 different >>> textures/materials. 7 are 512x512, and 1 is 256x256. >>> - We have 2 lights in the scene. >>> - I've added a basic "clone" keyboard event handler that clones the >>> character mesh and adds the clone to the scene. >>> - We're trying to simulate "unique" characters in the test. >>> Different textures, different geometry, etc. We are trying not to take >>> advantage of instancing, as our application eventually will have many >>> unique >>> characters in the scene. >>> - At the moment, all geometry in the scene is within the camera view. >>> Culling code is of course running, but everything is testing "in >>> frustum". >>> - Hardware: Core i7 Q740 1.73GHz with 8GB RAM. NVidia Quadro FX >>> 1800M GPU. >>> >>> The numbers: >>> >>> *# Chars / # Polys / FPS Range* >>> 1 3952 52-62 >>> 2 7904 41-47 >>> 3 11856 38-41 >>> 4 15508 32-34 >>> 5 19760 27-29 >>> 6 23712 21-27 >>> 7 27664 21-25 >>> 8 31616 18-22 >>> 9 35568 17-19 >>> 10 39520 15-18 >>> >>> The questions: >>> >>> 1. The Mesh.clone() method - does this meet the "unique characters" >>> requirement of my test above? Is there instancing going on underneath? >>> It >>> looks like clones share geometry and textures, but I may not have dug >>> deep >>> enough - the renderer itself may still create unique vertex buffers/etc >>> for >>> this data when rendered. >>> 2. These numbers seem abysmal in comparison to what I've seen in some >>> blog-posted molehill performance tests. I have not looked far under the >>> hood of these tests yet. (a) >>> http://iflash3d.com/performance/unity3d-vs-molehill/ (b) >>> http://www.nulldesign.de/2011/03/02/molehill-demo/. >>> 3. Based on what you know about your own internal architecture, and >>> limitations of molehill, is there anything obvious in what i'm doing >>> above >>> that would be causing the abysmal performance? Big textures? >>> >>> Any additional thoughts would be most welcome. >>> >>> -Dave >>> >> >> >> >> -- >> Michael Ivanov ,Programmer >> Neurotech Solutions Ltd. >> Flex|Air |3D|Unity| >> www.neurotechresearch.com >> http://blog.alladvanced.net >> Tel:054-4962254 >> [email protected] >> [email protected] >> >> > >
