> Actually, it doesn't even know that it's the backside :). yeah stoopid Linux planes! :)
> Texture/UV mapping has to be adjusted whenever the size of the > furniture changes Using the Projector class and a simple modulo would have allowed you define repeats the same way yet using parts. > Changing the furniture size, number of subdivisions etc. would > require a rebuild of the geometry which can be costly. I have no insight of the whole project, but sometimes dedicated primitives are the way to go Not trying here by any mean to crack your work btw, Was just pointing out that these artefacts could be wipped away doing this way. but indeed requires more time/preparation. Which is also a factor money/time. That having said, you can be proud of your work despite the sorting issues, its a lot of work and the result speak for itself. Well done! Fabrice On Oct 13, 2010, at 4:41 PM, banal wrote: > Hi Fabrice > > I thought about that too (in the beginning of the project the backside > was actually separated into different parts). > > The reason why I didn't implemented it the way you mentioned: > - The backside of the closet doesn't actually know anything about the > number of subdivisions and their sizes (they're not always the same). > Actually, it doesn't even know that it's the backside :). > - Texture/UV mapping has to be adjusted whenever the size of the > furniture changes (you'll notice that the textures will keep the same > size, even when you resize the furniture). This is much easier with a > simple geometry such as it is now. > - Changing the furniture size, number of subdivisions etc. would > require a rebuild of the geometry which can be costly. > > I guess the main cause for the z-sorting problems is the fact, that > all "wood-parts" or "planks" are the same class. These "planks" are > being laid out (positioned, transformed) using different layout- > algorithms. So the backside of the closet is the same class as the > door or a shelf. The parts are not aware of other parts and cannot > have additional geometry (vertices) added when another part was > added.. > This could also become very very complicated if one column has 3 > shelves and the one next to it has 7 shelves. Then the separating > piece would have to be adjusted accordingly as well. > > The goal of the current system was to make its classes reusable for > other furniture-types. But it also has the drawbacks you noticed :) > It was also more important to create a generic system and not one that > is specialized to work around z-sorting issues. > > Interestingly I also never had any feedback like yours where the z- > sorting seems to be a massive showstopper. Other people didn't seem to > bother that much (although somebody thought it was because he was > using the Linux-Version of the flash player which I thought was > funny). > > Cheers and thanks for your replies so far! > Roman > > On Oct 13, 3:58 pm, Fabrice3D <[email protected]> wrote: >> The artefact reveals the back of the furniture are made of one straight piece >> while a series of either Planes or SkinExtrudes could be defined in case of >> your 3 rows example >> be as from left to right >> >> var a = thickness; >> var b = width column; >> >> [ a, a+b] [a*2+b, a*2+b*2 ] [a*3+b*2, a*3+b*3 ] >> >> The back builded this way, you get continuous modeling, probably fixing >> almost all your issues. >> Means of course you need to subdivide on height as well to make all vertexes >> fit if required. >> >> Fabrice >> >> On Oct 13, 2010, at 3:31 PM, Michael Iv wrote: >> >>> Some of the stuff in our project was dynamically attached to the existing >>> geometry but I should admit we have not performed scaling etc.We also tried >>> to use hollow wall geometry as little as possible because it is one of the >>> major causes for such kind of artifacts. >> >>> Look ,your project is really impressive ,besides that drawback of Z sorting >>> , I am sure you will find the way to fix it. :) >> >>> Cheers. >> >>> On Wed, Oct 13, 2010 at 3:12 PM, banal <[email protected]> wrote: >>> You have a point but I think it's still not doable in our case. I gave >>> layering (pushback/pushfront) a try at some point during the project >>> but it didn't work out. >>> This is why I think layering won't work in our case: >>> - The viewer has to be generic. We cannot implement a layering ruleset/ >>> engine for every kind of furniture. I.e. a layering approach must work >>> the same for a table a closet or a bed... >>> - Parts of the furniture can grow quite big (eg. the backside of the >>> closet or the doors) and will always cause z-sorting issues with >>> smaller parts (eg. the doorknob). >>> - Geometry (like drawers, doorknobs, etc.) can be integrated into the >>> shop *without* adding any actionscript code or having to re-compile >>> the application (geometry is unknown). So it's not possible to create >>> special layering rules for some of the geometry since they are >>> basically all the same class. >> >>> I wonder: Was the app you're speaking of also that dynamic? Did object >>> sizes, distances and relations change? Did you have to deal with >>> "unknown" geometry? If yes, maybe you could outline your layering- >>> approach? It would be interesting to read about it. >> >>> Another option for the furniture rendering could be to switch into >>> "wireframe" mode during user-navigation... like in old 3D programs. >>> But IMHO the current approach is still better than that. >> >>> Cheers - Roman >> >>> On Oct 13, 2:39 pm, Michael Iv <[email protected]> wrote: >>>> I thing you can play around with layering .It can solve those problems.To >>>> tell you the truth as for an occasional visitor these artifacts are too >>>> noticable and pretty screw up the overall visual perception.Those artifacts >>>> are really big. I once wrote an Away3D app where there were complex nested >>>> models with hollow walls ,close adjacent planes ,etc.I could not afford to >>>> use Z-Sorting filter because of the same reason as you said.But I solved >>>> the >>>> problems with putting all the content into a container and then layering >>>> the >>>> children using pushback/front , ownCanvas and Sprite sessions. It takes >>>> some >>>> time to tweak the configs but eventually it delivers the desired result. >> >>>> On Wed, Oct 13, 2010 at 2:32 PM, banal <[email protected]> wrote: >>>>> Umm yes, you are right. >>>>> But I cannot revise the modeling approach, since most of the furniture >>>>> geometry is generated on the fly (the structure of the furniture is >>>>> actually defined in the backend, not in flash). Also: you can >>>>> configure and adjust so many things, you'll never be able to model/ >>>>> generate the geometry in a way that will *never* cause z-sorting >>>>> issues. >> >>>>> I currently use the following workaround, since the correct z-renderer >>>>> is way to slow: >>>>> When you rotate the furniture, then it uses the basic renderer. As >>>>> soon as movement stops, the furniture gets rendered with the correct z- >>>>> order rendering.... >> >>>>> I think it's an acceptable compromise and I don't see a better >>>>> solution until we get some sort of real z-buffer in flash. >> >>>>> Cheers - Roman >> >>>>> On Oct 13, 1:54 pm, Michael Iv <[email protected]> wrote: >>>>>> The app look fine generally but you have got a lot of artifacts on your >>>>>> furniture. Do you Z sort it? may be you should revise the modeling >>>>> approach >>>>>> ? >> >>>>>> On Wed, Oct 13, 2010 at 1:36 PM, banal <[email protected]> wrote: >>>>>>> Hello Developers >> >>>>>>> I thought I'd share this project with you that I have been working on >>>>>>> the past months. >>>>>>> It's a tool where the user can customize his own furniture. Currently >>>>>>> it's only for closets but will be extended to other types of furniture >>>>>>> in the near future. >> >>>>>>> The 3D preview of the furniture was done using Away3D. >>>>>>> Currently the tool and the website are German only, but I guess you'll >>>>>>> get what it's about by simply playing around :) >> >>>>>>> Website:http://www.deinmoebel.ch/ >>>>>>> Direct link to the furniture-configurator:http://shop.deinmoebel.ch/ >> >>>>>>> Cheers - Roman >> >>>>>> -- >>>>>> Michael Ivanov ,Programmer >>>>>> Neurotech Solutions Ltd. >>>>>> Flex|Air >>>>> |3D|Unity|www.neurotechresearch.comhttp://blog.alladvanced.nethttp:// >>>>> www.meetup.com/GO3D-Games-Opensource-3D/ >>>>>> Tel:054-4962254 >>>>>> [email protected] >>>>>> [email protected] >> >>>> -- >>>> Michael Ivanov ,Programmer >>>> Neurotech Solutions Ltd. >>>> Flex|Air >>>> |3D|Unity|www.neurotechresearch.comhttp://blog.alladvanced.nethttp://www.meetup... >>>> Tel:054-4962254 >>>> [email protected] >>>> [email protected] >> >>> -- >>> Michael Ivanov ,Programmer >>> Neurotech Solutions Ltd. >>> Flex|Air |3D|Unity| >>> www.neurotechresearch.com >>> http://blog.alladvanced.net >>> http://www.meetup.com/GO3D-Games-Opensource-3D/ >>> Tel:054-4962254 >>> [email protected] >>> [email protected]
