tag:blogger.com,1999:blog-6950833531562942289.post1091631961664408147..comments2024-03-25T03:36:48.099-07:00Comments on C0DE517E: Decoupling the scene treeDEADC0DEhttp://www.blogger.com/profile/01477408942876127202noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-6950833531562942289.post-22104174587408153892008-12-14T14:26:00.000-08:002008-12-14T14:26:00.000-08:00orenf: no I can't, unfortunately I'm really busy a...orenf: no I can't, unfortunately I'm really busy and that's also why you don't see so frequent updates on my blog anymore. But there are plenty of ways of contacting me, I've also included a MSN applet on the right...<BR/><BR/>That said, the main point of the article is that scene trees are pretty good for authoring packages, but make no sense when rendering, as we seldom want to traverse the objects in the tree hiearchy order, we need different orders and categories based on different needs (i.e. visibility vs rendering vs shadowmaps etc). So the best thing is to keep hierarchies in our file formats (tool pipeline) but then feed those to our render objects, that will extract the information they need to render and trash the ones we don't.DEADC0DEhttps://www.blogger.com/profile/01477408942876127202noreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-33044346194768250132008-12-12T08:02:00.000-08:002008-12-12T08:02:00.000-08:00can you please rewrite this article? I feel like t...can you please rewrite this article? I feel like there is something very important I can learn here from you but your writing style is just so abhorrent that I cannot follow at all. Please don't take that personally, but it is quite clear without the timestamp at the bottom that you indeed published this post at 3:03 am.Orenhttps://www.blogger.com/profile/03572151880529147137noreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-14540217789056456772008-02-22T05:32:00.000-08:002008-02-22T05:32:00.000-08:00Important topic. I think common scene graph that i...Important topic. I think common scene graph that includes all render data (tranformations, visibility, materials, meshes) realy bad idea for current game engines - the system becomes very solid and unmanagable - but its goot for tools like maya, max... <BR/> An engine may consists of forest of transformations trees and some hierarchies for bounds space casting (Octree, AABB tree, grids,...) which may used for frustrum culling or some game logic... All this are independent systems... George.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-26842866787820669842008-02-04T23:19:00.000-08:002008-02-04T23:19:00.000-08:00Thanks for reminding me the obvious. But for most ...Thanks for reminding me the obvious. But for most implementations, that name is incorrect (well of course, a tree is a kind of graph...) as they can't manage generic graphs at all, but are restricted to trees.DEADC0DEhttps://www.blogger.com/profile/01477408942876127202noreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-40830452348007456902008-02-04T01:02:00.000-08:002008-02-04T01:02:00.000-08:00It is usually call "scene graph".And is not naive,...It is usually call "scene graph".<BR/>And is not naive, it is used in many industry production, like OpenInventor, Maya.Anonymousnoreply@blogger.com