*"I didn't mean to imply it's not a good feature, I'm just saying we
can't prioritize it over all the other features and improvements we
are working on at this point"*

Like Octrees to work ? ;)

On Tue, May 24, 2011 at 12:53 PM, richardolsson <[email protected]> wrote:

> I didn't mean to imply it's not a good feature, I'm just saying we
> can't prioritize it over all the other features and improvements we
> are working on at this point. If you want to give it a shot and
> contribute then that's great! But again, we can't guarantee that
> it would make it into the engine (although if it's well architected
> and works well chances are it would.)
>
> I can guarantee you that we are very committed to keeping file sizes
> (as well as parsing speed) down, which is why we've made sure that
> AWD2 in that regard is vastly superior to other formats that are in
> general use.
>
> Also, if you find any issues with any file formats (like 3DS), then
> please file a bug and let us know. Either via e-mail or on this list,
> or using the issue tracker at
> www.github.com/away3d/away3d-core-broomstick/issues
> .
>
>
> Looking forward to hearing about your progress with smoothing!
>
> Thanks! :)
>
> /R
>
>
> On May 24, 10:38 am, themightyatom <[email protected]> wrote:
> > Michael > I think client side smoothing would help with your issue
> > too, as it offers endless LOD possibilities.
> > E.g. use a low.poly wheel at distance (8 sided), the 3 iteration
> > smoothed one close up.(64 sided)
> > You could also adjust the LOD depending on device, using the same
> > assets, simply by monitoring the actual FPS and/or screen size.
> > There's a paper by the PS2 team on this. (will try and find the
> > link...)
> >
> > Richard > I'm going to sound like a 40 something who still remembers
> > modems (which I am), but the only time I ever think of bandwidth as
> > "not a problem" is working locally :)
> > Mobile internet means this issue will be with us for a long time to
> > come, (bandwidth and charges) not to mention device memory capacity.
> > If I can shave 10% off filesize, without deterioration, I would
> > generally do it. Shaving 90% off has got to be interesting hasn't it?
> > If another file format is smaller to start off with, then even better.
> > (had a few probs with .3ds in Broomstick and found .OBJ more stable
> > i.e. models loaded every time without normals flipped/facets etc. will
> > test again with latest build)
> >
> > If it should prove to take 10 minutes to run a smoothing algorithm in
> > Flash, then I'm totally with you, but I can't imagine that will be the
> > case. In a java example I've seen it's almost instant.
> > I'll start with an AS3 implementation, just to get familiar with the
> > maths, but if that's too slow, maybe a PixelBender shader would be the
> > answer?
> >
> > For my current project scenario it would be a one time operation when
> > a model first loads, with fallback to low poly when viewed at
> > distance, or with many objects in the scene.
> >
> > I will gladly share my test results here, and would be delighted to
> > contribute to this fabulous engine :)
> >
> > Skål!
> >
> > Pete
> >
> > On May 23, 6:53 pm, richardolsson <[email protected]> wrote:
> >
> >
> >
> >
> >
> >
> >
> > > It's an interesting idea, but bandwidth is not really as big a problem
> > > as you would think if you choose formats that are more optimized than
> > > OBJ. Looking at geometry only, 3DS tends to be about 40% of an OBJ
> > > containing the same data, and deflated AWD2 is about 20%. So if you
> > > would use AWD (as will be our recommendation once Away3D 4.0 and AWD
> > > is stable), you would likely be able to store the smoothed model in
> > > 250kb, which is not that bad.
> >
> > > Still, it's an interesting idea, and I would be keen to see some
> > > benchmarks on how quickly the smoothing can be calculated in AS3.
> > > Simple sub-division is of course rather quick, but smoothing is likely
> > > a bit more complex and I'm not convinced the actual operation of
> > > smoothing the geometries would be fast enough (especially on lower end
> > > CPUs) to provide any substantial improvement over loading high-res
> > > models in optimized formats.
> >
> > > If you are interested in trying it out and contribute the code, let us
> > > know, and we can discuss it!
> >
> > > Cheers
> > > /R
> >
> > > On May 23, 1:40 pm, Michael Iv <[email protected]> wrote:
> >
> > > > Adding more subdivisions is not the biggest problem here as it seems
> to me,
> > > > but rather that Molehill is not so strong as native OpenGL to
> > > > run smoothly such high res models .Anyhow would like to see such a
> feature
> > > > in Away3D :)
> >
> > > > On Mon, May 23, 2011 at 2:04 PM, themightyatom <
> [email protected]>wrote:
> >
> > > > > Now we've finally got the power to display high-res models in Flash
> > > > > via Molehill, the next bottleneck seems to be bandwidth.
> > > > > In 3D Studio MAX I am often using TurboSmooth on relatively
> low-poly
> > > > > models, taking them from 100Kb, to 1.2Mb when exported as .OBJ
> >
> > > > > It struck me that if we could implement TurboSmooth, or similar
> > > > > smoothing algorithm in the client, we could send low res models
> over
> > > > > the wire, and have them come out smooth in the browser.
> >
> > > > > Is anybody working on this in Broomstick? I've got loads of
> examples
> > > > > of the "theory", but the only source I can find is OpenGL/C++ (and
> > > > > pages of it)
> > > > >http://www.holmes3d.net/graphics/subdivision/
> >
> > > > > I will be looking into Loop Scheme myself, but any pointers,
> examples,
> > > > > help, etc. greatly appreciated :O)
> >
> > > > > Cheers,
> >
> > > > > Pete
> >
> > > > --
> > > > Michael Ivanov ,Programmer
> > > > Neurotech Solutions Ltd.
> > > > Flex|Air |3D|Unity|www.neurotechresearch.comhttp://
> blog.alladvanced.net
> > > > Tel:054-4962254
> > > > [email protected]
> > > > [email protected]




-- 
Michael Ivanov ,Programmer
Neurotech Solutions Ltd.
Flex|Air |3D|Unity|
www.neurotechresearch.com
http://blog.alladvanced.net
Tel:054-4962254
[email protected]
[email protected]

Reply via email to