🔒 Locked
🎮 Unity
Engine Architecture Question
Advertisement
Original Post
Ok guys, so im making my first engine, and things are going really well, it's based on OpenGl. And basically the architecture is thus, I currently have a Game class, within that I am employing the object factory method, creating each object in the game and storing it within a linked list. This all works fine,and each cycle each objects update() and then render() functions are called. I have working skybox, ms3d importer, particle engine, fft water model. its not that impressive yet but nevertheless heres an old vid http://www.icarusfalls.co.uk/EngineDemo.WMV My question is this. My particle engine is working fine but i need billboarding to work. For this im going to calculate the angle from the camera x,y,z to the particle x,y,z the maths is fine, but obviously the particle engine needs to be able to 'see' the xyz of the camera. My game class contains a pointer to the camera objCamera. however as my particles are updated via the linked list i cant really overload the update function to take the camera's x,y,z parameters. My thoughts are to create a static camX,camY,camZ within my Particle class, and then update these in my game update() code each cycle i.e, Particle::camX = objCamera.posX; Particle::camY = objCamera.posY; Particle::camZ = objCamera.posZ; I'm fairly certain this will work, im just wondering what your thoughts are from an OOP architecture point of view? Are there better ways of achieving this? Many thanks
My advice is to use OpenGL's ARB_point_sprite extensions to create point sprites, hardware accelerated billboards. They are pretty cool for particle systems because you only have to send a single vertex point for each particle instead of four vertices for a regular billboarded quad and you won't have to mess with the orientation.
Here you go:
http://www.codesampler.com/source/ogl_point_sprites.zip
Here you go:
http://www.codesampler.com/source/ogl_point_sprites.zip
Look into message passing. It'll solve the problem you have there with your particle system and camera, and you'll probably find a million other uses for it. Basically, every frame, have your Camera class construct a message containing it's xyz. Note that sending the message is not the job of your Camera class; all it should do is construct the message and make it available. It's the responsibility of the class which owns your camera class (ie. your Game class) to take that message, and send it wherever it's needed. This keeps things simple (your Camera class never needs to know about your Particle class, or any other, keeping your program's overall coupling low), it's immensely powerful, and it's in keeping with OOP paradigms.
Have a search on Google for messaging systems. There are a lot of different ways of doing it. Find one you like, and use it :)
Have a search on Google for messaging systems. There are a lot of different ways of doing it. Find one you like, and use it :)
[edited] reading :)
Thanks guys! The hardware billboards definately sound like the way to go! Time to rewrite my particle engine! :)
As for message handling, im just comming upto the stage where i need to *properly* implement keyboard and joystick input, and that sounds like an ideal solution!! I can see its uses, will get reading on that straight away!
Thanks to both of you for taking the time to reply :)
As for message handling, im just comming upto the stage where i need to *properly* implement keyboard and joystick input, and that sounds like an ideal solution!! I can see its uses, will get reading on that straight away!
Thanks to both of you for taking the time to reply :)
Quote:
Original post by chipmeisterc
Thanks guys! The hardware billboards definately sound like the way to go! Time to rewrite my particle engine! :)
As for message handling, im just comming upto the stage where i need to *properly* implement keyboard and joystick input, and that sounds like an ideal solution!! I can see its uses, will get reading on that straight away!
Thanks to both of you for taking the time to reply :)
Message passing is certainly a fine thing to do in general.
For the case of rendering stuff, I have a "render context" that gets set up at scene begin that get stuffed with "things that could be useful for objects that are rendering" such as the view matrix. That way, you're not passing a ton of parameters around (just the context).
Quote:
Original post by nsto119
Does anyone know of any tutorials for message-passing systems? I've been interested in them for a while, but I can't ever really find a good explanation or how-to.
There doesn't seem to be much. A cursory search of the forums for "event system" bought up a few interesting results; there might be more in Articles & Resources.
It's fairly easy to implement message-passing, at least in a basic way. Have a bit of a think about it :)
You're going to have to funnel a LOT more data between your objects before you're done with a real game. I suggest that you design some system that will let objects find other objects that they are interested in, and talk to them to get updates about data quantities that are needed.
One way of doing this is to use the "execution environment" style.
Another is to "mount" all objects somewhere in a "file system"-like space, like what Nebula does.
One way of doing this is to use the "execution environment" style.
Another is to "mount" all objects somewhere in a "file system"-like space, like what Nebula does.
Quote:
Original post by iNsAn1tY Quote:
Original post by nsto119
Does anyone know of any tutorials for message-passing systems? I've been interested in them for a while, but I can't ever really find a good explanation or how-to.
There doesn't seem to be much. A cursory search of the forums for "event system" bought up a few interesting results; there might be more in Articles & Resources.
It's fairly easy to implement message-passing, at least in a basic way. Have a bit of a think about it :)
Well, I have ideas, I've thought about it a bit. But since I've never really seen more about them than vague descriptions on this site, I'm not sure if it's what most people would consider a true message-passing system.
Quote:
Original post by hplus0603
One way of doing this is to use the "execution environment" style.
Sounds interesting; could you give a short explanation what
exactly you mean with that?
(a 'context' with usefull info like one of the previous posters
mentioned, or more like a global var/class with info? or sth else?)
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement