Graylien

Members
  • Content count

    932
  • Joined

  • Last visited

Community Reputation

160 Neutral

About Graylien

  • Rank
    Advanced Member
  1. Google Scholar is also free from ads and paid query results, so your searches should tend to turn up more scientific content and less commercial results. For example, if you're looking for something related to 3D graphics hardware then you're probably not interested in an online store hawking video cards or the latest nVidia press release. Frequently you'll find papers only available via the ACM Digital Library, but sometimes those very same papers are available from other sources that Google crawls (i.e. a university tech report version, which often is exactly the same paper as the published version only with more data and/or pictures because there are no space constraints). I often start with Google Scholar or CiteSeer and then expand my search with normal Google whenever I have a hard time getting a PDF copy of the paper I'm looking for. But since I have access to both the ACM Digital Library and IEEE Xplorer it's rare that I can't get ahold of something. Here are the IEEE and IEEE Society Dues. I'm not a member, and I'm no longer a member of the ACM either so I don't know all the benefits that go along with membership. I'll probably join when I'm no longer a student ... and who knows when that will be!
  2. Pretty much all information services are available for free via a University network. The ACM Digital Library is one I use often, but I also use IEEE Xplorer and even Books24x7.com where I can read complete books before deciding if I want to buy them. Of course, CiteSeer is still one of my favourites, as is Google Scholar. As for owning the work coming out of Universities, NO ONE OWNS IT. Authors retain copyright, of course, but the whole idea of academic publication is that the information is made available to the world. If you publish through a journal, then the publisher (e.g. ACM) controls the certain aspects too. But nobody owns the ideas, and nobody owns the work.
  3. Graphic "Engine" Threads?

    Quote:Original post by OrangyTang Yes, and its performance suffered horribly because of it. The performance of Java3D sucked for many reasons, not just because the scene graph was designed for multithreaded rendering. Quote:Thats a nonsense. You've only got one current scene, and one graphics card. Two threads trying to draw two objects at the same time is just plain silly. Either you've drawing to two different contexts (in which case you're going to do wasteful context switches) or you're drawing into the same context, in which case you'll get race conditions and conflicting state. Two threads wanting to draw is not the same as two threads simultaneously drawing. Obviously you don't want to be continuously switching rendering contexts or device states. Again, concurrency can be a design advantage if not always a performance one. Quote:Already done for you via graphics drivers, DMA and the like. Almost all graphics calls will be non-blocking and allow the driver to queue commands and copy data around later. Agreed, but allow me to clarify. I'm specifically thinking of situations where independent branches of the scene graph may require CPU-intensive work. You need to squeeze every ounce of usage out of limited CPU-GPU bandwidth, so you never want to risk data starvation. This is not a common problem, but it's a valid suggestion nonetheless. If my GPU was waiting for data and 50% of my multicore CPU was idle because the graphics engine only had one thread, I'd be unhappy.
  4. Graphic "Engine" Threads?

    My research area is concurrency so naturally I'm biased. I haven't done 3D graphics for a few years so I'm afraid I don't have any concrete examples off the top of my head. Naturally any multiprocessor system (including CPUs with multiple cores) can take advantage of a threaded design. Don't forget about SLI video card systems. I haven't looked deeply into CELL yet but I do know that it's designed around parallel data pumping. I remember the ill-fated Java3D API had as an explicit design goal the facilitation of multithreaded rendering. The scene graph was constructed to be thread-safe. Naturally, you wouldn't do this unless there was some good reason. Consider the case of two threads each wanting to draw a different node in the scene graph. Imagine one thread spending CPU time to compute some aspect while the second thread streams its data to the GPU; they could alternate forever like this. Alternatively, you could have some worker threads labouring to optimize the scene graph ahead of the traversal of the thread responsible for rendering. Or how about re-balancing a branch of an AB-tree before the next time it's needed? I should note that using threads to partition a system isn't always about concurrency. Often it can simplify design (note that design is not equal to implementation, programming or debugging). Think about a sequential system as being a special case of a concurrent one - a system with a single thread - and you'll be in the right headspace.
  5. Graphic "Engine" Threads?

    I use threads and concurrency everywhere. It's the only way to go! Quote:Original post by WanMaster I would recommend to build the engine, system, game, whatever first, and see if seperate threads will improve things once you've finished these. Designing threads in after the fact only makes things like debugging worse. With proper design rigour concurrent systems need not be any harder than ordinary sequential systems.
  6. Render-Order Sorting

    I'll try an answer for each of your three questions (in order). 1. You do not need to sort your scene manually. The author of the paper you cite isn't clear when he says "it is possible to render everything in the front to back order without causing any major render state changing overhead" because that's always true if you never change the render state. The mention of "front to back order" seems to imply that you have to sort your own geometry, but I don't believe this is what the author really means. He just means that render states don't affect the depth values in the z-buffer in this situation. 2. Firstly you want to ensure that when you use the one of the Direct3D Clear() methods instead of, say, rendering a black rectangle at maximum depth to achieve a "similar" effect. (Some people still do this.) For ATI cards employing HyperZ this is crucial to the proper behaviour of their pipeline optimizations. At this point you can render your geometry in the absence of any lighting, textures, pixel shaders, etc. When rasterizing naked vertices the real target is the depth/stencil buffer and not the frame buffer. After doing this, you render your scene as you normally would. The idea here is that the HyperZ technology will kill many pixels very early in the pipeline, thus saving the expense of actually going through the pixel shaders or whatever. 3. I think maybe the author's mention of minimizing render state changes in both quotes is what's confusing you. In this example of multi-pass rendering you're populating the depth buffer by quickly rendering naked vertices: No render states, let alone state changes. Afterwards in the second pass (which you order however you wish) HyperZ kicks in to trivially reject some pixels ... although you'll still want to watch your state changes.
  7. Thanks. I hadn't read those threads (like I said it's been awhile) and since the search function is still borked I figured I'd try the "human search" tactic. My problem with adaptive binary trees is the need for periodic rebalancing and their inherent fuzziness. They may produce a tighter PVS but I've never cared for the runtime overhead. However it's probably something I should look into. Part of my dilemma is that I'm trying to merge several data structures into one (e.g. spatial partitioning, collision detection, etc.), which often isn't the best idea.
  8. It's been awhile since I've dabbled in 3D programming. I'm behind the curve and a little rusty so please bear with me! I've come across a lot of contradictory information with regards to dynamic geometry and visibility determination. More specifically, it seems many people disagree with how best to handle moving objects when you're using the typical spatial partitioning tree structures (e.g. BSP trees, quadtrees, octrees). Some say that the overhead in maintaining such data structures precludes using them on anything but static geometry. Furthermore they say that the relative paucity of dynamic objects means it's far more efficient to rely solely on a simple view frustrum intersection test. However others claim that the runtime shuffling of mobile objects within the culling structure exploits enough frame coherence to be very advantageous. Naturally, there probably isn't one best way; life's never that simple. But I was wondering what people here think. I'm sure there's quite a list of pros and cons for each side.
  9. Wikipedia Vandalism

    Outright vandalism is wrong but unavoidable even with the self-policing nature of Wikipedia. Sometimes it can be hilarious though. I enjoy wasting time clicking through the Bad jokes and other deleted nonsense part of Wikipedia. Examples: Quote:From 2109 2109-All animals are taken over or eaten by robots, they are consumed as light snacks. Robots learn to reproduce with their gigantic huge and delicous metal dicks. They become horny 24/7. Quote:From Fen Fens were a 3-legged race of migrant smelly dwarves who nobody really liked but were uncertain how to get rid of in a nice way.They had a habit of making cucumber & eggy pies which tended to give them really awful gas which they had no qualms about sharing with whomever might be nearby.Although this was all done in a jovial nature it did not endear them in the least to the general population of England.Gertrit Mortldue is credited with ridding the Isles of them by starting a small, but effective, army of followers who befriended these dwarves and put gunpowder in their pies whenever they were not looking. Then the next time a Fen passed gas to a cohort he (or she) was blown to Smithereens. Smithereens is a small Isle off the coast of................
  10. Computer Engineer or Programmer??

    Forget about the money for now. You're in your first year of University, and thus a long ways from earning a paycheck. Your career comes later, and as long as you stick with computer/software/electrical engineering or computer science then you will fine in terms of future employment. Looking up the average salary 3-4 years in advance of your first job is misleading. How much coin you earn will depend on a lot of things, including how well you do in school now. If the math is a stumbling block then be warned that you'll probably have to do it anyways in computer science. Advanced (i.e. interesting) courses in computer science assume this level of mathematics. Just to be clear, when you say "computer programmer" you are referring to computer science, correct? Because if you're only interested in programming, then be warned that not all programs emphasize this; some are more theoretical in nature.
  11. Google's Blogger.com

    I was rooting through the Baghdad Burning archives, much like a pig in shit, and I found multiple discrepancies that quite clearly indicate that while the author may be Iraqi, she is clearly not in Iraq. It's not worth my time to explicitly point out these flaws. Nevertheless, this is one of the most popular blogs on Blogger.com, and the only way you get to the top is if people keep talking about you. (And of course, linking to you. Hence my timorous decision not to supply evidence.)
  12. BREW/J2ME

    Quote:Original post by Anonymous Poster J2ME: doesn't require any verification Java Verified While the signing/verification process is not required, I get the feeling that one day it will be (but as you said, signing is only an issue if you intend to resell via a carrier portal).
  13. The physical size of the display and the pixel area of the canvas are two different things. For example, look at the monitor in front of you. Notice the black band around the visible area? Since you're using J2ME, the getWidth() and getHeight() methods of the Canvas class give you the proper size of the display. The values returned by the methods should match the documentation of whatever phone you wish to program for.
  14. BREW/J2ME

    Many carriers are shifting towards requiring some sort of formal testing, be it "Java Verified" in the case of J2ME or "Symbian Signed" in the case of Symbian OS. While I think this is a step in the right direction, I'm not pleased at how expensive the testing process can be. [EDIT] Two sentences, three tenses. I'll never post before my morning coffee again.
  15. Name this emoticon

    Bullfrog