Fabrice, thanks again. That makes enough sense to keep me going for now. I'll have a lot to learn when I transition to Away3D 4 I am sure!
Best, BW On Wed, Mar 30, 2011 at 9:11 AM, Fabrice3D <[email protected]> wrote: > Are you saying LineSegment will be the preferred approach in Away3D 4, > or just that Segments in Meshes are not available yet? > > LineSegment will stay as is, lines in mesh will be added, what will change > its the management > we need to have dedicated transforms per object > > now, if you use LineSegment, it fills a single entity, the segments you get > are simply an indice refs to this entity buffer > because thats the only way to allow you to modify the segment properties at > runtime. > In case of a Mesh with debug, you actually do not care at all , so it will > fill a buffer once, no segments required here > once you say mesh.debug false, it will simply destroy that buffer. > but one will be aware of the mesh matrix, this other is like in 3.6 and > lower, you can simply set start/end position or color as you please. > CurveSegments will no change this, internally it will only add more entries > to the vertices buffer. The manager however in case > you build a shape with say [LineSegment, CurveSegment, LineSegment], if you > decide to remove the CurveSegment, not only a variable length of entries > will be removed in vertices list but the segments will also get an updated > index, as you would still love to say mysecondLineSegment.start = > myFirstSegement.end. > as on init the indices were 0,1,2, once 1 is gone, it needs to informed [2] > that the new indice has become [1]. So aside the add/delete segments > routines somebody needs to know > who to inform, in which entity and if an instance ref such as CurveSegment > or LineSegment exists, their respective index needs update. Plus of course > the entities management as well > as you would not like to get resource limits, buffer full or empty etc... > > hope this makes sens to you. > > Fabrice > > > On Mar 30, 2011, at 5:23 PM, Bob Warfield wrote: > > 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] >>> >>> >> >> > >
