Honours Project Topic Idea

September 28th, 2009


closeThis post was published 2 years 7 months 21 days ago and as such probably does not reflect my current opinions, knowledge or ability.

Term has only just begun but already it is time to come to some decisions in terms of my honours project topic. I’m finding it tough as there are a lot of areas I’m interested in but don’t feel I have sufficient prior knowledge to pursue an honours project around, such as AI or networking. Meanwhile, there are areas with too much information, too little work to base research on, too expansive a practical project involved… At this stage I’m hoping that I can focus my project to one general area where I know there is a mountain of resources available, and narrow in my work in order to define a research question.

l2

In order to aid us in deciding upon a topic and creating a proposal, we’re being given a series of worksheets which will be reviewed by another member of the class. My responses to the first of these follows:

1. State the topic of interest that you may wish to take forward into a project.

Compilers and languages.
Specifically, to aid procedural geometry design and creation.

Overall, I want to look into how a simple script can be compiled into geometry, or into an executable which produces geometry. Looking at this the other way around, this also means considering how geometry can best be thought of as a series of rules for its creation. By storing models in this way it should become easier to create variations in design, which in turn could add depth to scenery and commonly reused objects in games.

l1

2. Indicate the issues surrounding this topic that you may wish investigate.

There are a number of inter-related issues surrounding this area concerning language design, compiler creation, and generating useful geometry. General choices concerning the target use and users of the language should help focus research towards the most relevant issues.

In terms of language and compiler design, there would be a number of considerations:

  • Symbolic vs. spatial grammers (i.e. specifying rules in terms of textual symbols, or in terms of shapes)
  • Context free vs. contextual grammers (i.e. whether how a rule is used, or which rules were applied previously, would affect its outcome)
  • Deterministic vs. non-deterministic rules
  • Interpretation as part of an application (e.g. as a game loads) vs. compilation to a polygonal model format beforehand vs. compilation to a series of geometry producing functions in another language.
  • How best can a tool be designed to cut down on stock content creation time?
  • Can it improve existing content and levels?
  • How can complexity/orthogonality be minimised through language design?
  • Does the language design allow for emergent and unexpected behaviours, and should they be minimised or encouraged?

l5

In terms of geometry creation and use, there are a range of issues which could influence language design:

  • How would the geometry created relate to animation and texturing?
  • Can this method help create simplified models for L.o.D?
  • How would a scene with multiple models be organised?
  • Can graphics hardware improve performance when producing geometry?
  • Could geometry shaders be used at some points to improve rendering performance?
  • Can rules be applied to existing models or do we need to start with basic primitives?
  • How can noise and pseudo-random values reduce rules required and add variety to content produced?
  • Are the same techniques relevant to organic and structural modelling?
  • What architectural techniques are relevant to this process?
  • Would the aim be to create individual models or a complete scene?

Additionally, some issues arise in terms of performance and optimisation:

  • How would the geometry creation process scale?
  • Can parallelisation techniques improve performance?
  • How could using the same part of a model repeatedly by optimised?

l3

3. Outline your initial ideas about how you would carry out the practical aspects of the project. i.e. what do you envisage yourself actually doing for the project.

  1. Design a simple language which allows the user to specify hierarchical rules in order to create and improve 3D models or a 3D scene. Of course, this will be based on research in procedural geometry and programming language design.
  2. Create a tool to parse and compile this language to give model data, or functions for creating model data, in terms of vertices and polygons. This would be the major focal point of practical and research work, based on reading in compiler creation and on the language designed.
  3. Create a demonstration set of rules in the language with an application to show the resulting geometry.

My biggest concern with this topic will be in reducing the scope to fit within the limited time we have available. The project can be seen to split into two research areas: compiler/language design and geometry creation and in order for this to be honours project it will almost certainly be necessary to focus on only one of these. Compilers are an area I really hope to research but I want to avoid creating another useless and throwaway scripting language, so I think this topic will allow me to do some more interesting study. It’s still early days though, so we’ll see where this heads.

As usual, thoughts, criticism, suggestions and ideas would be greatly appreciated.

l4

Image thanks to woodleywonderworks.



Related Posts


Comments

  1. like you say that’s a lot of stuff to do, but you can probably narrow it down to the stuff you really want to do/the most useful stuff/whatever ozveren approves of (delete as necessary)

    i wouldn’t really spend any time looking at rendering of your geometry unless it was complex and dynamic and entirely implemented with geo shaders then you’ll probably be best off just letting something else render your creations.

  2. Hazel says:

    Thanks Stuart,
    I think I need to research creating the geometry in order to design the language but you’re right – I should just rule out anything to do with rendering right away.

    As you say, I’m pretty much just looking at ways to cut this down and focus on one particular aspect. Figured I’d let it get torn apart by a few people first though ;)

  3. one tip just to remember: be careful the question about “performance” or “real time”, if you don’t want to stuck with all the unnecessary(probably not very fun too :p) measurement.

    will be back if i can remember anything else :p
    Good luck!

  4. unless you strongly want to become an Engine programmer :D

  5. Hazel says:

    Good point… I hadn’t really considered how much “extra” work there might be in measuring and comparing performance.
    I want to focus on the compiler as much as possible and if the geometry does not need to be created in real time as part of a game application performance would be a far more minor concern. I’ll try to bear that in mind when forming my research question and (eventually) designing the tool/language.
    Thanks :D

  6. Mike McTaggart says:

    Very well thought out idea Hazel, you clearly have a lot of ideas and have put thought into the project as a whole. My main thought when reading it was the timescale available for the honours project – however you addressed this in the last paragraph. Is there a way to reduce the scope of the entire project if time does become an issue?

  7. Hazel says:

    Thanks for the feedback Mike.
    Timescale is absolutely the biggest issue I am contending with right now. Even though I listed a huge number of points I could consider, I’d only hope to address one or two of these with my research question. In terms of reducing the scope of the entire project I do this primarily by focussing on compiler theory (and area in which there is a mountain of information and research) to a far greater extent than procedural geometry, and by keeping the language designed as simple as possible.
    I am still considering other compiler related projects to investigate which might be more fitting given the time available.

  8. Martin Whyte says:

    Hi Hazel, I like the idea! Do you have any idea what you’d use your tool for? Procedural geometry is quite a wide field, do you plan to specialise in procedural people, environments (trees etc) or something else?

    Oddly enough I’m doing something a little like this at work just now, though it’s just a very very simple scripting method set.

  9. Hazel says:

    Hi Martin, great to hear from you.

    At the moment I’m not entirely decided what type of geometry/models I’d be looking at – the main contenders right now are plants/trees, modern architecture and man made scenery (lamp-posts, bins… that sort of thing).

    Architecture has the advantage that I’ve found a lot of very useful papers demonstrating how I might approach constructing buildings, but obviously even this is still a wide area.
    Trees and plants could mean basing the model design around L-systems, which would also give the scripting language a clear direction.
    As for throw away, non-natural scenery I think it’s an area that could benefit from being created procedurally rather than hand modelled but at the same time it would require a far more flexible tool.

    I hadn’t actually considered procedural people before now and I am very tempted to investigate further.

    Really encouraging to hear you’re working on something even remotely similar – hope it goes well :)

  10. Hey Hazel, just (re)-discovered your blog again, and saw this post. It sounds like a fascinating project.

    One way to cut down on the scope (but to still focus on compiler design) would be to adopt a language such as Lisp. That way you can skip much of the dull stuff (syntax, parsing, lexing etc…) and concentrate on writing the compiler.

    Because it’s homoiconic (code is data), Lisp is a great language for such things and has traditionally been used to write compilers and prototype new language paradigms. The secret is of course Lisp Macro’s (as I’m sure you know) which make the whole of Lisp available to you at Compile time, and allow you to transform expand/reduce the s-expressions (AST) at compilation time.

    Having done precisely this on a project recently (creating a domain specific, specification and query language, which was both expressive, and also easily transformed into a diagramatic decision tree) I can testify that it really is incredibly easy to do, and is every bit as powerful as the Lisp evangelists say =)

    If you want easy access to 3D libraries etc then you could look at Clojure, which is a great modern Lisp dialect with an amazing foreign-function-interface that really isn’t foreign at all. You’d then have dead simple access into java3D or JOGL (Java OpenGL bindings)… Or if you want it even easier there is the penumbra wrapper:

    http://github.com/ztellman/penumbra

    For an example of clojure/opengl/penumbra code, there’s a tetris example here in about 200 LOC:

    http://github.com/ztellman/penumbra/blob/master/src/examples/tetris.clj

    If you need .net access then, Clojure also has a CLR port.

    http://clojure.org/

    If the approach interests you, then I’d be happy to speak to you about it at a LUG meeting.

    Have fun!

  11. Hazel says:

    Hey Rick,
    Thanks a lot for the suggestions.

    Although I’m focussing on research rather than implementation at this stage I’m in no way fixed to working in C/C++ as I have been with many university projects, so it’s great to get recommendations on approaches I could take. I’d be nervous about adopting a language that I have no practical experience with such as Lisp however I do have some time before I would begin the experimental aspects of the project so I definitely wouldn’t rule it out.

    I’m pretty sure you have extolled the virtues of Clojure at a previous LUG meeting so again, it’s something I’ll investigate further and consider.

    A previous recommendation I received involved using a combination of C# (which I am fairly proficient with) and F# for separate parts of the project. Since, as you mention, there is a CLR port of Clojure then using that alongside C# might also be an option.

    In terms of 3D geometry, I’m still unsure whether it would be more suitable to produce 3D model data in some standard form (.fbx, .obj etc) or to create code to generate the geometry which could be used elsewhere. Either way, this data would only be used and rendered in a separate application which I would keep as minimal as possible.

    Thanks again for all your advice, I really appreciate it; I’ll definitely try to get to more LUG meetings and discuss ideas.

Leave a Reply