Starsonata Wiki - User contributions [en]

GalDev:Client2SigSlot

2009-11-19T03:47:35Z

BlindSide:

== GUI Element Signals ==

(Note on "item based" elements. These include listbox, combobox, table, contextmenu and generally any element that holds a list of items. For tables "item" generally refers to a row.)

'''value_changed''': (Param is core::stringw) Sent by all gui elements when the value changes. For scrollbars and such this would be the numerical value in the form of a string, and for item-based elements such as list it will send the text of the selected item (Not the user data) if an item is selected.

'''checkbox_checked''': (No params) Sent by a checkbox when it becomes checked.

'''checkbox_unchecked''': (No params) Sent by a checkbox when it becomes unchecked.

'''button_clicked''': (No params) Sent by a button when a button is clicked. Specifically this means that the button was held down and then the mouse was released over the button comfirming the action.

'''button_down''': (No params) Sent by a button when it is held down for the first time.

'''button_up''': (No params) Sent by a button when it is released (Even if the mouse is not over the button).

'''item_selected_text''': (Param is core::stringw) Sent by item based elements when a new item is selected. It sends the text of the new item.

'''item_selected_index''': (Param is core::stringw) Sent by item based elements when a new item is selected. It sends the numerical index in the form of a string of the new item.

'''item_selected_data''': (Param is core::stringw) Sent by item based elements when a new item is selected. It sends the user data in the form of a string of the new item.

'''hidden''': (No params) Sent when a gui element is set non-visible (Not sent when it's destroyed!).

'''revealed''': (No params) Sent when a gui element was previously non-visible and is now visible (Not sent when it's created).

'''created''': (No params) Sent when a gui element is first created.

== GUI Element Slots ==

'''setText''': (Param is core::stringw) Takes a string and uses it to set the element data. For item-based elements each item will be seperated by a delimiter. For tables each field separated by a delimiter indicates a cell and the data will wrap around to a new row based on the number of columns. For scrollbars and such this will be the numerical value in the form of a string.

'''setUserData''': (Param is core::stringw) Takes a string and uses it to set the element user data. For item-based elements each item will be seperated by a delimiter. For tables each field separated by a delimiter indicates a cell and the data will wrap around to a new row based on the number of columns.

GalDev:Client2SigSlot

2009-11-19T03:46:45Z

BlindSide: New page: == GUI Element Signals == (Note on "item based" elements. These include listbox, combobox, table, contextmenu and generally any element that holds a list of items. For tables "item" gene...

== GUI Element Signals ==

(Note on "item based" elements. These include listbox, combobox, table, contextmenu and generally any element that holds a list of items. For tables "item" generally refers to a row.)

value_changed: (Param is core::stringw) Sent by all gui elements when the value changes. For scrollbars and such this would be the numerical value in the form of a string, and for item-based elements such as list it will send the text of the selected item (Not the user data) if an item is selected.

checkbox_checked: (No params) Sent by a checkbox when it becomes checked.

checkbox_unchecked: (No params) Sent by a checkbox when it becomes unchecked.

button_clicked: (No params) Sent by a button when a button is clicked. Specifically this means that the button was held down and then the mouse was released over the button comfirming the action.

button_down: (No params) Sent by a button when it is held down for the first time.

button_up: (No params) Sent by a button when it is released (Even if the mouse is not over the button).

item_selected_text: (Param is core::stringw) Sent by item based elements when a new item is selected. It sends the text of the new item.

item_selected_index: (Param is core::stringw) Sent by item based elements when a new item is selected. It sends the numerical index in the form of a string of the new item.

item_selected_data: (Param is core::stringw) Sent by item based elements when a new item is selected. It sends the user data in the form of a string of the new item.

hidden: (No params) Sent when a gui element is set non-visible (Not sent when it's destroyed!).

revealed: (No params) Sent when a gui element was previously non-visible and is now visible (Not sent when it's created).

created: (No params) Sent when a gui element is first created.

== GUI Element Slots ==

setText: (Param is core::stringw) Takes a string and uses it to set the element data. For item-based elements each item will be seperated by a delimiter. For tables each field separated by a delimiter indicates a cell and the data will wrap around to a new row based on the number of columns. For scrollbars and such this will be the numerical value in the form of a string.

setUserData: (Param is core::stringw) Takes a string and uses it to set the element user data. For item-based elements each item will be seperated by a delimiter. For tables each field separated by a delimiter indicates a cell and the data will wrap around to a new row based on the number of columns.

GalDev:Client2GenericGui

2009-11-08T12:09:14Z

BlindSide: New page: This page is a reference for all the reserved generic signals/slots in the new ui. These will be used for generic messageboxes/input boxes:

This page is a reference for all the reserved generic signals/slots in the new ui. These will be used for generic messageboxes/input boxes:

Development/Client2GuiConversion

2009-10-06T13:46:28Z

BlindSide: Removing all content from page

Development/Client2GuiConversion

2009-09-30T21:38:00Z

BlindSide: /* Client 2 Gui Conversion Guide */

Note: Sorry the wiki formatting is kind of difficult for me, if someone can make the code snippets look better it would be much appreciated.

== Client 2 Gui Conversion Guide ==

This page is meant as a guide for converting old client 2 gui functionality over to the new system. Some of these steps are meant for clarity and to fit the new coding guidelines and thus can be skipped if one is tight on time. These will be marked as optional, although in all likely cases they should still be performed as long as they don't take much time to do so.

The intention of this conversion is to separate the game logic code from the abstracted gui code while retaining the base functionality and re-using as much code as possible.

Throughout this guide I will be using xfer_funds_dlg.h and .cpp as an example on how to convert the old logic functionality as it is a fairly simple class and will serve this purpose sufficiently.

[Optional] 1. Rename class to camel case and a name more fitting for a logic class rather than a gui class. If the previous name is convoluted it would be preferable to use something more clear.

''E.g. Change the class name from GuiDlgXferFunds to FundsTransferManager.''

2. Remove the inheritance " : public GuiWindow" and any another GuiWindow related inheritance or derivations unless they are central to the class's operation. This includes "virtual bool Load(const std::string &filename_)", although be sure to check for any important game-logic related code in "virtual bool Load(const std::string &filename_)", if it's only adding event handlers and storing pointers to gui elements then those can be safely removed, this functionality will be replaced by the signal system in the new gui design. In the case of GuiDlgXferFunds the entire function can be removed, just be sure to keep in mind the list of functions that it assigned event handling to as this may prove useful in the later stages of the conversion.

By now GuiDlgXferFunds's declaration should look like this:

''class FundsTransferManager
{
public:
FundsTransferManager(irr::gui::IGUIElement* parent_);

void Clear();

long64 GetCredits() const;

private:
irr::gui::IGUIEditBox * m_credits;
};''

3. The constructor for most classes that inherit from GuiWindow will usually take a parent gui element or some other gui-related parameter. These should usually be discarded with certain logic-specific parameters considered on a case by case basis. In the case of GuiDlgXferFunds the constructor parameter can be removed. In the constructor the class will usually attempt to set it's "Name" instance variable and perform other gui-related functions. These should also be considered if they seem central to the logic's operation but in the case of GuiDlgXferFunds we can just remove all of that. This actually removes the need for a constructor in this particular case altogether.

By now GuiDlgXferFunds's declaration should look like this:

''class FundsTransferManager
{
public:
void Clear();

long64 GetCredits() const;

private:
irr::gui::IGUIEditBox * m_credits;
};''

4. Old gui-game-logic classes usually keep pointers to relevant elements so they can be easily accessed. The new system will send and receive signals instead and does not need to be aware of the actual gui elements. The instance variables for these can be removed also. Be careful to only remove gui related instance variable, usually marked as being in the "gui::" namespace.

By now GuiDlgXferFunds's declaration should look like this:

''class FundsTransferManager
{
public:
void Clear();

long64 GetCredits() const;
};''

5. Convert base functionality to work with the new signals system. This part is hard because it usually involves changing/refactorying other files/classes due to the old code's "immediate mode" nature, where as this new code is "signal" or "event" based. The difference in philosophy is that in the old code an action would be performed during an event and then the change in state would be read and transferred as a message.

For example GuiPropManage creates a GuiDlgXferFunds, waits for the ok button to be clicked and for it to return, validates the result to be EDR_OK and then retrieves the amount in credits the player would like to transfer from GuiDlgXferFunds before sending the message. In the new system GuiDlgXferFunds should create the network message and send it directly upon receiving the signal that the ok button was clicked. GuiDlgXferFunds will either query the value from the edit box element by accessing the element through the name/id of the element OR it will receive the value in the form of a signal sent by the textbox element (Will need to Dorth's opinion on the intended usage here).

- To Be Continued -

Development/Client2GuiConversion

2009-09-30T21:37:00Z

BlindSide: /* Client 2 Gui Conversion Guide */

== Client 2 Gui Conversion Guide ==

This page is meant as a guide for converting old client 2 gui functionality over to the new system. Some of these steps are meant for clarity and to fit the new coding guidelines and thus can be skipped if one is tight on time. These will be marked as optional, although in all likely cases they should still be performed as long as they don't take much time to do so.

The intention of this conversion is to separate the game logic code from the abstracted gui code while retaining the base functionality and re-using as much code as possible.

Throughout this guide I will be using xfer_funds_dlg.h and .cpp as an example on how to convert the old logic functionality as it is a fairly simple class and will serve this purpose sufficiently.

[Optional] 1. Rename class to camel case and a name more fitting for a logic class rather than a gui class. If the previous name is convoluted it would be preferable to use something more clear.

''E.g. Change the class name from GuiDlgXferFunds to FundsTransferManager.''

2. Remove the inheritance " : public GuiWindow" and any another GuiWindow related inheritance or derivations unless they are central to the class's operation. This includes "virtual bool Load(const std::string &filename_)", although be sure to check for any important game-logic related code in "virtual bool Load(const std::string &filename_)", if it's only adding event handlers and storing pointers to gui elements then those can be safely removed, this functionality will be replaced by the signal system in the new gui design. In the case of GuiDlgXferFunds the entire function can be removed, just be sure to keep in mind the list of functions that it assigned event handling to as this may prove useful in the later stages of the conversion.

By now GuiDlgXferFunds's declaration should look like this:

''class FundsTransferManager
{
public:
FundsTransferManager(irr::gui::IGUIElement* parent_);

void Clear();

long64 GetCredits() const;

private:
irr::gui::IGUIEditBox * m_credits;
};''

3. The constructor for most classes that inherit from GuiWindow will usually take a parent gui element or some other gui-related parameter. These should usually be discarded with certain logic-specific parameters considered on a case by case basis. In the case of GuiDlgXferFunds the constructor parameter can be removed. In the constructor the class will usually attempt to set it's "Name" instance variable and perform other gui-related functions. These should also be considered if they seem central to the logic's operation but in the case of GuiDlgXferFunds we can just remove all of that. This actually removes the need for a constructor in this particular case altogether.

By now GuiDlgXferFunds's declaration should look like this:

''class FundsTransferManager
{
public:
void Clear();

long64 GetCredits() const;

private:
irr::gui::IGUIEditBox * m_credits;
};''

4. Old gui-game-logic classes usually keep pointers to relevant elements so they can be easily accessed. The new system will send and receive signals instead and does not need to be aware of the actual gui elements. The instance variables for these can be removed also. Be careful to only remove gui related instance variable, usually marked as being in the "gui::" namespace.

By now GuiDlgXferFunds's declaration should look like this:

''class FundsTransferManager
{
public:
void Clear();

long64 GetCredits() const;
};''

5. Convert base functionality to work with the new signals system. This part is hard because it usually involves changing/refactorying other files/classes due to the old code's "immediate mode" nature, where as this new code is "signal" or "event" based. The difference in philosophy is that in the old code an action would be performed during an event and then the change in state would be read and transferred as a message.

For example GuiPropManage creates a GuiDlgXferFunds, waits for the ok button to be clicked and for it to return, validates the result to be EDR_OK and then retrieves the amount in credits the player would like to transfer from GuiDlgXferFunds before sending the message. In the new system GuiDlgXferFunds should create the network message and send it directly upon receiving the signal that the ok button was clicked. GuiDlgXferFunds will either query the value from the edit box element by accessing the element through the name/id of the element OR it will receive the value in the form of a signal sent by the textbox element (Will need to Dorth's opinion on the intended usage here).

- To Be Continued -

Development/Client2GuiConversion

2009-09-30T21:35:35Z

BlindSide: /* Client 2 Gui Conversion Guide */

== Client 2 Gui Conversion Guide ==

This page is meant as a guide for converting old client 2 gui functionality over to the new system. Some of these steps are meant for clarity and to fit the new coding guidelines and thus can be skipped if one is tight on time. These will be marked as optional, although in all likely cases they should still be performed as long as they don't take much time to do so.

The intention of this conversion is to separate the game logic code from the abstracted gui code while retaining the base functionality and re-using as much code as possible.

Throughout this guide I will be using xfer_funds_dlg.h and .cpp as an example on how to convert the old logic functionality as it is a fairly simple class and will serve this purpose sufficiently.

[Optional] 1. Rename class to camel case and a name more fitting for a logic class rather than a gui class. If the previous name is convoluted it would be preferable to use something more clear.

''E.g. Change the class name from GuiDlgXferFunds to FundsTransferManager.''

2. Remove the inheritance " : public GuiWindow" and any another GuiWindow related inheritance or derivations unless they are central to the class's operation. This includes "virtual bool Load(const std::string &filename_)", although be sure to check for any important game-logic related code in "virtual bool Load(const std::string &filename_)", if it's only adding event handlers and storing pointers to gui elements then those can be safely removed, this functionality will be replaced by the signal system in the new gui design. In the case of GuiDlgXferFunds the entire function can be removed, just be sure to keep in mind the list of functions that it assigned event handling to as this may prove useful in the later stages of the conversion.

By now GuiDlgXferFunds's declaration should look like this:

<nowiki>
class FundsTransferManager
{
public:
FundsTransferManager(irr::gui::IGUIElement* parent_);

void Clear();

long64 GetCredits() const;

private:
irr::gui::IGUIEditBox * m_credits;
};</nowiki>

3. The constructor for most classes that inherit from GuiWindow will usually take a parent gui element or some other gui-related parameter. These should usually be discarded with certain logic-specific parameters considered on a case by case basis. In the case of GuiDlgXferFunds the constructor parameter can be removed. In the constructor the class will usually attempt to set it's "Name" instance variable and perform other gui-related functions. These should also be considered if they seem central to the logic's operation but in the case of GuiDlgXferFunds we can just remove all of that. This actually removes the need for a constructor in this particular case altogether.

By now GuiDlgXferFunds's declaration should look like this:

<nowiki>class FundsTransferManager
{
public:
void Clear();

long64 GetCredits() const;

private:
irr::gui::IGUIEditBox * m_credits;
};</nowiki>

4. Old gui-game-logic classes usually keep pointers to relevant elements so they can be easily accessed. The new system will send and receive signals instead and does not need to be aware of the actual gui elements. The instance variables for these can be removed also. Be careful to only remove gui related instance variable, usually marked as being in the "gui::" namespace.

By now GuiDlgXferFunds's declaration should look like this:

<nowiki>class FundsTransferManager
{
public:
void Clear();

long64 GetCredits() const;
};</nowiki>

5. Convert base functionality to work with the new signals system. This part is hard because it usually involves changing/refactorying other files/classes due to the old code's "immediate mode" nature, where as this new code is "signal" or "event" based. The difference in philosophy is that in the old code an action would be performed during an event and then the change in state would be read and transferred as a message.

For example GuiPropManage creates a GuiDlgXferFunds, waits for the ok button to be clicked and for it to return, validates the result to be EDR_OK and then retrieves the amount in credits the player would like to transfer from GuiDlgXferFunds before sending the message. In the new system GuiDlgXferFunds should create the network message and send it directly upon receiving the signal that the ok button was clicked. GuiDlgXferFunds will either query the value from the edit box element by accessing the element through the name/id of the element OR it will receive the value in the form of a signal sent by the textbox element (Will need to Dorth's opinion on the intended usage here).

- To Be Continued -

Development/Client2GuiConversion

2009-09-30T21:31:02Z

BlindSide: New page: == Client 2 Gui Conversion Guide == This page is meant as a guide for converting old client 2 gui functionality over to the new system. Some of these steps are meant for clarity and to f...

BlindSide Log

2009-05-30T06:49:26Z

BlindSide:

= BlindSide's Star Sonata Development Journal =

== May 29th ==

LOG HAS MOVED: http://www.starsonata.com/forum/viewtopic.php?f=9&t=32706

== May 23rd ==

More work on per-pixel lighting today. For those who know a thing or two about lighting mathematics, I scrapped the traditional attenuation formula for a simple (1.0 - distance / radius), works much better now. I also had a play around with a rim light (Originally intended for planet atmospheres but I think it tends to look nice on ships too.). A rim light is the fading white outline you see in the following image:

[[Image:RimLight.png]]

Believe it or not, there's still no bump mapping in that shot. Then again, I reckon that bumpmapping will have a more noticeable effect on things like planets and bigger ships. I'll hack that in and report back.

<nowiki>** Some Time Passes **</nowiki>

OK! Bump maps are in!

Here is a comparison using a shrimp (Top shows bumpmapping, bottom no bumpmapping):

[[Image:ShipBump.jpg]]

And a planet (Top shows bumpmapping again):

[[Image:PlanetBump.jpg]]

These are just preliminary results of course, I plan to add specular reflections to oceans on planets and lots of other goodies. See you next time on BSDL! (Yes I think an acronym sounds cooler...)

== May 21st ==

Today I started on per-pixel lighting. I am supposed to go ahead and implement bumpmapping, rim lighting, and whatever effects I feel like stuffing in the shader to make it look pretty.

Now, what is per-pixel lighting? Let's start with a brief explanation:

In legacy graphics, lighting is calculated on a per-vertex level, for example, for your standard n dot l (normal dot product light direction) style lighting, it would be calculated for each vertex, based on the vertex normal, and then interpolated across the triangle. It typically produces ugly triangle shaped artifacts in under tessellated models (Models with a small amount of triangles).

Something like this (Images thanks to LightHouse3d):

[[Image:PointGL.gif]]

Per-pixel on the other hand, performs the operation on every pixel, without the need to interpolate the final result across the triangle. It's typically more computationally expensive, but the results speak for themselves:

[[Image:PointPix.gif]]

Here is a side by side comparison of just ordinary lighting applied to a Zebu (No bumpmaps). The one on the left is per-pixel and the one on the right is fixed function per-vertex lighting. Particularly near the cockpit you can make out how the per-pixel lighting approach produces a more distinct result, where as the lighting on the per-vertex version looks rather vague:

[[Image:ZebuPerPix.jpg]]

Please note that the per-pixel version is using slightly different material settings and therefore it is slightly darker.

Also, earlier in the forums I posted up a screenshot of the pax frigate. I think this is one of the ships that benefit the most in particular from per-pixel lighting. With the same viewing angle and position, this is the old shot:

[[Image:OldPaxFrigate.jpg]]

And this is the new (Note this was taken on Very High so it has anti-aliasing applied too unlike the old shot):

[[Image:NewPaxFrigate.jpg]]

That's all for today, folks.

== May 19th ==

Added quite a few things since the last post, namely lightning style lasers. Jade Ion is now a combination of animated lightning and beam rather than a static custom image. I would post a screenshot but it won't do it justice, better to see it moving. Some lightning style lasers such as Really Big Laser are using pure lightning, and stuff like shield transference still use a static core texture (Screenshot in last post).

On the lasers side I've also added some particles that emit from the firing point to create a sort of muzzle effect. Will need to test this with really big lasers (I don't specifically refer to Really Big Laser here).

For explosions, I enhanced the look by using a seperate particle texture (And system), and made them only refract on ships. Sparklers take the sob size into account now, when available (Had to modify husk and spacebase to supply sizes to sparklers, as this was only implemented for explosions.).

Ok that's me for today, catch you next time on BlindSide Development Log! :P

[Pip Comment] - ''I think we should open this log to everyone BS, what do you think?''

[BlindSide's response] - ''BlindSide's Star Sonata Development log grand opening! I like the sound of that. (I also like the sound of my own voice, lol)''

== May 17th ==

I spent more time fixing wormholes and a few other things today. I made a small video showing the two seperate parts of a wormhole, they are combined in the final product: http://irrlichtirc.g0dsoft.com/BlindSide/wh.wmv

Anyway enough about that, I added a cool bulge to lasers:

[[Image:LaserBulge.jpg]]

Particle effects:

[[Image:LaserParticle.jpg]]

Custom core textures:

[[Image:LaserYingYang.jpg]]

== May 16th ==

Something was annoying me about the last screenshot, it's the hard end that the lasers have, it looks very unprofessional (Like the C1 lasers :P, not baggin' on C1 or anything). I scratched my head for some time on how to get rid of this without resorting to to textures (Which means scrapping the whole geometry idea and starting from scratch). Solution: More geometry! I think I am getting better at writing meshes by hand. Mind you I only added 3 vertices, but the end result speaks for itself:

[[Image:LaserDev7.jpg]]

Now to add some more variation as promised!

== May 14th ==

Lasers of course should have an overly bright bit in the center, so with some more hacking I got this:

[[Image:LaserDev6.jpg]]

Note that I don't use any textures for this, the laser is purely geometry and the color variation is from blending the vertex colors. This should in theory prove more efficient than a texture based solution, and more importantly it allows us to set any arbitary colors we want without extra hassle.

== May 13th ==

Finally it is lasers time! Lasers are certainly one of the more interesting graphics elements. Few methods/variations arise:

- Criss cross 2 billboards to create a beam effect, fairly simple.

No textures are needed here as we can just 2 more vertices and interpolate the vertex color from black at the edges to whatever the color is in the center.

- I could place one or two of those billboard volume light scene nodes on
the beam to create a bit more variation,

I'm always meaning to use them somewhere but haven't found the place.

- A better idea would be to just use an elongated sphere and only render
the bumps/animations on the lasers in the glow pass.

This should create a nice effect, I will probably try this method first.

- For wide area laser/tractory type things a cone with scrolling textures
(Via texture matrices would be appropriate).

I will probably just use whatever texture is provided with C1 and scroll that along the 3 dimensional cone, should come out nice.

Well I am off to implement them and will hopefully have some screenshots in a few hours!

(Some time passes)

Ok, first of all, lets get acquainted with the Laser space objects. Process the start and endpoints and draw a simple line for debug output:

[[Image:LaserDev1.jpg]]

Oh dear that does not look right. Oh yes! The laser is using relative coordinates. Subtract that laser's position from the endpoint:

[[Image:LaserDev2.jpg]]

That's more like it!

Now let's make it look more like a laser. After a bit of magic (And a complete re-write of an already available laser scene node for Irrlicht), we get something like this:

[[Image:LaserDev3.jpg]]

Now that's starting to look more like a laser! Let's try some glow and see what we get:

[[Image:LaserDev4.jpg]]

OK, maybe that's a little too much glow! Let's reduce the laser's radius when applying glow:

[[Image:LaserDev5.jpg]]

It's getting better! Next time we'll try adding a green light to the front of the ship when it fires a laser (Other surprises are in store!). That's all for today, stay tuned.

[Pip Comment] - ''Starting to look very nice. Any way to add a bit of variation up and down the beam?''

[BlindSide response] - ''Thanks for your comment pip! The lasers will indeed get some variation once the basic look is perfected.''

== May 12th ==

I've been improving the background generation on/off. On my Phenom 9950 system (2.6 ghz, Only using one core):

- Low/Medium settings take 60 milliseconds to generate the background nebula.
- High+ settings take ~400 milliseconds to generate the background nebula.

I may consider moving this to the gpu for better performance, as high settings systems will undoubtedly support this functionality (I would use the same code that creates the animated patterns on the suns, so it should be pretty damn fast). We'll see.

Currently the background is placed on a flat billboard but I am considering moving this to a hemisphere/quarter-sphere(?) to create a more 3 dimensional feeling.

[Smiley Comment] ''I assume the background will be the same each time you visit the same galaxy, correct? Its just generating the SAME nebula based on parameters set at universe creation, correct? I think the galaxies should keep their "look" from visit to visit.''

[BlindSide reply] ''Thanks for the comment Smiley! That is correct, the nebula generator currently uses the galaxy id as the seed for the generation, so visiting the same galaxy twice would give you the same look and colors. ''

[[Category:Client_2_Dev]]

BlindSide Log

2009-05-30T06:49:07Z

BlindSide:

= BlindSide's Star Sonata Development Journal =

== May 29th ==

LOG HAS MOVED: [http://www.starsonata.com/forum/viewtopic.php?f=9&t=32706]

== May 23rd ==

More work on per-pixel lighting today. For those who know a thing or two about lighting mathematics, I scrapped the traditional attenuation formula for a simple (1.0 - distance / radius), works much better now. I also had a play around with a rim light (Originally intended for planet atmospheres but I think it tends to look nice on ships too.). A rim light is the fading white outline you see in the following image:

[[Image:RimLight.png]]

Believe it or not, there's still no bump mapping in that shot. Then again, I reckon that bumpmapping will have a more noticeable effect on things like planets and bigger ships. I'll hack that in and report back.

<nowiki>** Some Time Passes **</nowiki>

OK! Bump maps are in!

Here is a comparison using a shrimp (Top shows bumpmapping, bottom no bumpmapping):

[[Image:ShipBump.jpg]]

And a planet (Top shows bumpmapping again):

[[Image:PlanetBump.jpg]]

These are just preliminary results of course, I plan to add specular reflections to oceans on planets and lots of other goodies. See you next time on BSDL! (Yes I think an acronym sounds cooler...)

== May 21st ==

Today I started on per-pixel lighting. I am supposed to go ahead and implement bumpmapping, rim lighting, and whatever effects I feel like stuffing in the shader to make it look pretty.

Now, what is per-pixel lighting? Let's start with a brief explanation:

In legacy graphics, lighting is calculated on a per-vertex level, for example, for your standard n dot l (normal dot product light direction) style lighting, it would be calculated for each vertex, based on the vertex normal, and then interpolated across the triangle. It typically produces ugly triangle shaped artifacts in under tessellated models (Models with a small amount of triangles).

Something like this (Images thanks to LightHouse3d):

[[Image:PointGL.gif]]

Per-pixel on the other hand, performs the operation on every pixel, without the need to interpolate the final result across the triangle. It's typically more computationally expensive, but the results speak for themselves:

[[Image:PointPix.gif]]

Here is a side by side comparison of just ordinary lighting applied to a Zebu (No bumpmaps). The one on the left is per-pixel and the one on the right is fixed function per-vertex lighting. Particularly near the cockpit you can make out how the per-pixel lighting approach produces a more distinct result, where as the lighting on the per-vertex version looks rather vague:

[[Image:ZebuPerPix.jpg]]

Please note that the per-pixel version is using slightly different material settings and therefore it is slightly darker.

Also, earlier in the forums I posted up a screenshot of the pax frigate. I think this is one of the ships that benefit the most in particular from per-pixel lighting. With the same viewing angle and position, this is the old shot:

[[Image:OldPaxFrigate.jpg]]

And this is the new (Note this was taken on Very High so it has anti-aliasing applied too unlike the old shot):

[[Image:NewPaxFrigate.jpg]]

That's all for today, folks.

== May 19th ==

Added quite a few things since the last post, namely lightning style lasers. Jade Ion is now a combination of animated lightning and beam rather than a static custom image. I would post a screenshot but it won't do it justice, better to see it moving. Some lightning style lasers such as Really Big Laser are using pure lightning, and stuff like shield transference still use a static core texture (Screenshot in last post).

On the lasers side I've also added some particles that emit from the firing point to create a sort of muzzle effect. Will need to test this with really big lasers (I don't specifically refer to Really Big Laser here).

For explosions, I enhanced the look by using a seperate particle texture (And system), and made them only refract on ships. Sparklers take the sob size into account now, when available (Had to modify husk and spacebase to supply sizes to sparklers, as this was only implemented for explosions.).

Ok that's me for today, catch you next time on BlindSide Development Log! :P

[Pip Comment] - ''I think we should open this log to everyone BS, what do you think?''

[BlindSide's response] - ''BlindSide's Star Sonata Development log grand opening! I like the sound of that. (I also like the sound of my own voice, lol)''

== May 17th ==

I spent more time fixing wormholes and a few other things today. I made a small video showing the two seperate parts of a wormhole, they are combined in the final product: http://irrlichtirc.g0dsoft.com/BlindSide/wh.wmv

Anyway enough about that, I added a cool bulge to lasers:

[[Image:LaserBulge.jpg]]

Particle effects:

[[Image:LaserParticle.jpg]]

Custom core textures:

[[Image:LaserYingYang.jpg]]

== May 16th ==

Something was annoying me about the last screenshot, it's the hard end that the lasers have, it looks very unprofessional (Like the C1 lasers :P, not baggin' on C1 or anything). I scratched my head for some time on how to get rid of this without resorting to to textures (Which means scrapping the whole geometry idea and starting from scratch). Solution: More geometry! I think I am getting better at writing meshes by hand. Mind you I only added 3 vertices, but the end result speaks for itself:

[[Image:LaserDev7.jpg]]

Now to add some more variation as promised!

== May 14th ==

Lasers of course should have an overly bright bit in the center, so with some more hacking I got this:

[[Image:LaserDev6.jpg]]

Note that I don't use any textures for this, the laser is purely geometry and the color variation is from blending the vertex colors. This should in theory prove more efficient than a texture based solution, and more importantly it allows us to set any arbitary colors we want without extra hassle.

== May 13th ==

Finally it is lasers time! Lasers are certainly one of the more interesting graphics elements. Few methods/variations arise:

- Criss cross 2 billboards to create a beam effect, fairly simple.

No textures are needed here as we can just 2 more vertices and interpolate the vertex color from black at the edges to whatever the color is in the center.

- I could place one or two of those billboard volume light scene nodes on
the beam to create a bit more variation,

I'm always meaning to use them somewhere but haven't found the place.

- A better idea would be to just use an elongated sphere and only render
the bumps/animations on the lasers in the glow pass.

This should create a nice effect, I will probably try this method first.

- For wide area laser/tractory type things a cone with scrolling textures
(Via texture matrices would be appropriate).

I will probably just use whatever texture is provided with C1 and scroll that along the 3 dimensional cone, should come out nice.

Well I am off to implement them and will hopefully have some screenshots in a few hours!

(Some time passes)

Ok, first of all, lets get acquainted with the Laser space objects. Process the start and endpoints and draw a simple line for debug output:

[[Image:LaserDev1.jpg]]

Oh dear that does not look right. Oh yes! The laser is using relative coordinates. Subtract that laser's position from the endpoint:

[[Image:LaserDev2.jpg]]

That's more like it!

Now let's make it look more like a laser. After a bit of magic (And a complete re-write of an already available laser scene node for Irrlicht), we get something like this:

[[Image:LaserDev3.jpg]]

Now that's starting to look more like a laser! Let's try some glow and see what we get:

[[Image:LaserDev4.jpg]]

OK, maybe that's a little too much glow! Let's reduce the laser's radius when applying glow:

[[Image:LaserDev5.jpg]]

It's getting better! Next time we'll try adding a green light to the front of the ship when it fires a laser (Other surprises are in store!). That's all for today, stay tuned.

[Pip Comment] - ''Starting to look very nice. Any way to add a bit of variation up and down the beam?''

[BlindSide response] - ''Thanks for your comment pip! The lasers will indeed get some variation once the basic look is perfected.''

== May 12th ==

I've been improving the background generation on/off. On my Phenom 9950 system (2.6 ghz, Only using one core):

- Low/Medium settings take 60 milliseconds to generate the background nebula.
- High+ settings take ~400 milliseconds to generate the background nebula.

I may consider moving this to the gpu for better performance, as high settings systems will undoubtedly support this functionality (I would use the same code that creates the animated patterns on the suns, so it should be pretty damn fast). We'll see.

Currently the background is placed on a flat billboard but I am considering moving this to a hemisphere/quarter-sphere(?) to create a more 3 dimensional feeling.

[Smiley Comment] ''I assume the background will be the same each time you visit the same galaxy, correct? Its just generating the SAME nebula based on parameters set at universe creation, correct? I think the galaxies should keep their "look" from visit to visit.''

[BlindSide reply] ''Thanks for the comment Smiley! That is correct, the nebula generator currently uses the galaxy id as the seed for the generation, so visiting the same galaxy twice would give you the same look and colors. ''

[[Category:Client_2_Dev]]

File:PlanetBump.jpg

2009-05-24T08:17:11Z

BlindSide:

File:ShipBump.jpg

2009-05-24T08:17:06Z

BlindSide:

BlindSide Log

2009-05-24T08:16:55Z

BlindSide: /* May 23rd */

= BlindSide's Star Sonata Development Journal =

== May 23rd ==

More work on per-pixel lighting today. For those who know a thing or two about lighting mathematics, I scrapped the traditional attenuation formula for a simple (1.0 - distance / radius), works much better now. I also had a play around with a rim light (Originally intended for planet atmospheres but I think it tends to look nice on ships too.). A rim light is the fading white outline you see in the following image:

[[Image:RimLight.png]]

Believe it or not, there's still no bump mapping in that shot. Then again, I reckon that bumpmapping will have a more noticeable effect on things like planets and bigger ships. I'll hack that in and report back.

<nowiki>** Some Time Passes **</nowiki>

OK! Bump maps are in!

Here is a comparison using a shrimp (Top shows bumpmapping, bottom no bumpmapping):

[[Image:ShipBump.jpg]]

And a planet (Top shows bumpmapping again):

[[Image:PlanetBump.jpg]]

These are just preliminary results of course, I plan to add specular reflections to oceans on planets and lots of other goodies. See you next time on BSDL! (Yes I think an acronym sounds cooler...)

== May 21st ==

Today I started on per-pixel lighting. I am supposed to go ahead and implement bumpmapping, rim lighting, and whatever effects I feel like stuffing in the shader to make it look pretty.

Now, what is per-pixel lighting? Let's start with a brief explanation:

In legacy graphics, lighting is calculated on a per-vertex level, for example, for your standard n dot l (normal dot product light direction) style lighting, it would be calculated for each vertex, based on the vertex normal, and then interpolated across the triangle. It typically produces ugly triangle shaped artifacts in under tessellated models (Models with a small amount of triangles).

Something like this (Images thanks to LightHouse3d):

[[Image:PointGL.gif]]

Per-pixel on the other hand, performs the operation on every pixel, without the need to interpolate the final result across the triangle. It's typically more computationally expensive, but the results speak for themselves:

[[Image:PointPix.gif]]

Here is a side by side comparison of just ordinary lighting applied to a Zebu (No bumpmaps). The one on the left is per-pixel and the one on the right is fixed function per-vertex lighting. Particularly near the cockpit you can make out how the per-pixel lighting approach produces a more distinct result, where as the lighting on the per-vertex version looks rather vague:

[[Image:ZebuPerPix.jpg]]

Please note that the per-pixel version is using slightly different material settings and therefore it is slightly darker.

Also, earlier in the forums I posted up a screenshot of the pax frigate. I think this is one of the ships that benefit the most in particular from per-pixel lighting. With the same viewing angle and position, this is the old shot:

[[Image:OldPaxFrigate.jpg]]

And this is the new (Note this was taken on Very High so it has anti-aliasing applied too unlike the old shot):

[[Image:NewPaxFrigate.jpg]]

That's all for today, folks.

== May 19th ==

Added quite a few things since the last post, namely lightning style lasers. Jade Ion is now a combination of animated lightning and beam rather than a static custom image. I would post a screenshot but it won't do it justice, better to see it moving. Some lightning style lasers such as Really Big Laser are using pure lightning, and stuff like shield transference still use a static core texture (Screenshot in last post).

On the lasers side I've also added some particles that emit from the firing point to create a sort of muzzle effect. Will need to test this with really big lasers (I don't specifically refer to Really Big Laser here).

For explosions, I enhanced the look by using a seperate particle texture (And system), and made them only refract on ships. Sparklers take the sob size into account now, when available (Had to modify husk and spacebase to supply sizes to sparklers, as this was only implemented for explosions.).

Ok that's me for today, catch you next time on BlindSide Development Log! :P

[Pip Comment] - ''I think we should open this log to everyone BS, what do you think?''

[BlindSide's response] - ''BlindSide's Star Sonata Development log grand opening! I like the sound of that. (I also like the sound of my own voice, lol)''

== May 17th ==

I spent more time fixing wormholes and a few other things today. I made a small video showing the two seperate parts of a wormhole, they are combined in the final product: http://irrlichtirc.g0dsoft.com/BlindSide/wh.wmv

Anyway enough about that, I added a cool bulge to lasers:

[[Image:LaserBulge.jpg]]

Particle effects:

[[Image:LaserParticle.jpg]]

Custom core textures:

[[Image:LaserYingYang.jpg]]

== May 16th ==

Something was annoying me about the last screenshot, it's the hard end that the lasers have, it looks very unprofessional (Like the C1 lasers :P, not baggin' on C1 or anything). I scratched my head for some time on how to get rid of this without resorting to to textures (Which means scrapping the whole geometry idea and starting from scratch). Solution: More geometry! I think I am getting better at writing meshes by hand. Mind you I only added 3 vertices, but the end result speaks for itself:

[[Image:LaserDev7.jpg]]

Now to add some more variation as promised!

== May 14th ==

Lasers of course should have an overly bright bit in the center, so with some more hacking I got this:

[[Image:LaserDev6.jpg]]

Note that I don't use any textures for this, the laser is purely geometry and the color variation is from blending the vertex colors. This should in theory prove more efficient than a texture based solution, and more importantly it allows us to set any arbitary colors we want without extra hassle.

== May 13th ==

Finally it is lasers time! Lasers are certainly one of the more interesting graphics elements. Few methods/variations arise:

- Criss cross 2 billboards to create a beam effect, fairly simple.

No textures are needed here as we can just 2 more vertices and interpolate the vertex color from black at the edges to whatever the color is in the center.

- I could place one or two of those billboard volume light scene nodes on
the beam to create a bit more variation,

I'm always meaning to use them somewhere but haven't found the place.

- A better idea would be to just use an elongated sphere and only render
the bumps/animations on the lasers in the glow pass.

This should create a nice effect, I will probably try this method first.

- For wide area laser/tractory type things a cone with scrolling textures
(Via texture matrices would be appropriate).

I will probably just use whatever texture is provided with C1 and scroll that along the 3 dimensional cone, should come out nice.

Well I am off to implement them and will hopefully have some screenshots in a few hours!

(Some time passes)

Ok, first of all, lets get acquainted with the Laser space objects. Process the start and endpoints and draw a simple line for debug output:

[[Image:LaserDev1.jpg]]

Oh dear that does not look right. Oh yes! The laser is using relative coordinates. Subtract that laser's position from the endpoint:

[[Image:LaserDev2.jpg]]

That's more like it!

Now let's make it look more like a laser. After a bit of magic (And a complete re-write of an already available laser scene node for Irrlicht), we get something like this:

[[Image:LaserDev3.jpg]]

Now that's starting to look more like a laser! Let's try some glow and see what we get:

[[Image:LaserDev4.jpg]]

OK, maybe that's a little too much glow! Let's reduce the laser's radius when applying glow:

[[Image:LaserDev5.jpg]]

It's getting better! Next time we'll try adding a green light to the front of the ship when it fires a laser (Other surprises are in store!). That's all for today, stay tuned.

[Pip Comment] - ''Starting to look very nice. Any way to add a bit of variation up and down the beam?''

[BlindSide response] - ''Thanks for your comment pip! The lasers will indeed get some variation once the basic look is perfected.''

== May 12th ==

I've been improving the background generation on/off. On my Phenom 9950 system (2.6 ghz, Only using one core):

- Low/Medium settings take 60 milliseconds to generate the background nebula.
- High+ settings take ~400 milliseconds to generate the background nebula.

I may consider moving this to the gpu for better performance, as high settings systems will undoubtedly support this functionality (I would use the same code that creates the animated patterns on the suns, so it should be pretty damn fast). We'll see.

Currently the background is placed on a flat billboard but I am considering moving this to a hemisphere/quarter-sphere(?) to create a more 3 dimensional feeling.

[Smiley Comment] ''I assume the background will be the same each time you visit the same galaxy, correct? Its just generating the SAME nebula based on parameters set at universe creation, correct? I think the galaxies should keep their "look" from visit to visit.''

[BlindSide reply] ''Thanks for the comment Smiley! That is correct, the nebula generator currently uses the galaxy id as the seed for the generation, so visiting the same galaxy twice would give you the same look and colors. ''

[[Category:Client_2_Dev]]

BlindSide Log

2009-05-24T08:16:37Z

BlindSide: /* May 23rd */

= BlindSide's Star Sonata Development Journal =

== May 23rd ==

More work on per-pixel lighting today. For those who know a thing or two about lighting mathematics, I scrapped the traditional attenuation formula for a simple (1.0 - distance / radius), works much better now. I also had a play around with a rim light (Originally intended for planet atmospheres but I think it tends to look nice on ships too.). A rim light is the fading white outline you see in the following image:

[[Image:RimLight.png]]

Believe it or not, there's still no bump mapping in that shot. Then again, I reckon that bumpmapping will have a more noticeable effect on things like planets and bigger ships. I'll hack that in and report back.

** Time Passes **

OK! Bump maps are in!

Here is a comparison using a shrimp (Top shows bumpmapping, bottom no bumpmapping):

[[Image:ShipBump.jpg]]

And a planet (Top shows bumpmapping again):

[[Image:PlanetBump.jpg]]

These are just preliminary results of course, I plan to add specular reflections to oceans on planets and lots of other goodies. See you next time on BSDL! (Yes I think an acronym sounds cooler...)

== May 21st ==

Today I started on per-pixel lighting. I am supposed to go ahead and implement bumpmapping, rim lighting, and whatever effects I feel like stuffing in the shader to make it look pretty.

Now, what is per-pixel lighting? Let's start with a brief explanation:

In legacy graphics, lighting is calculated on a per-vertex level, for example, for your standard n dot l (normal dot product light direction) style lighting, it would be calculated for each vertex, based on the vertex normal, and then interpolated across the triangle. It typically produces ugly triangle shaped artifacts in under tessellated models (Models with a small amount of triangles).

Something like this (Images thanks to LightHouse3d):

[[Image:PointGL.gif]]

Per-pixel on the other hand, performs the operation on every pixel, without the need to interpolate the final result across the triangle. It's typically more computationally expensive, but the results speak for themselves:

[[Image:PointPix.gif]]

Here is a side by side comparison of just ordinary lighting applied to a Zebu (No bumpmaps). The one on the left is per-pixel and the one on the right is fixed function per-vertex lighting. Particularly near the cockpit you can make out how the per-pixel lighting approach produces a more distinct result, where as the lighting on the per-vertex version looks rather vague:

[[Image:ZebuPerPix.jpg]]

Please note that the per-pixel version is using slightly different material settings and therefore it is slightly darker.

Also, earlier in the forums I posted up a screenshot of the pax frigate. I think this is one of the ships that benefit the most in particular from per-pixel lighting. With the same viewing angle and position, this is the old shot:

[[Image:OldPaxFrigate.jpg]]

And this is the new (Note this was taken on Very High so it has anti-aliasing applied too unlike the old shot):

[[Image:NewPaxFrigate.jpg]]

That's all for today, folks.

== May 19th ==

Added quite a few things since the last post, namely lightning style lasers. Jade Ion is now a combination of animated lightning and beam rather than a static custom image. I would post a screenshot but it won't do it justice, better to see it moving. Some lightning style lasers such as Really Big Laser are using pure lightning, and stuff like shield transference still use a static core texture (Screenshot in last post).

On the lasers side I've also added some particles that emit from the firing point to create a sort of muzzle effect. Will need to test this with really big lasers (I don't specifically refer to Really Big Laser here).

For explosions, I enhanced the look by using a seperate particle texture (And system), and made them only refract on ships. Sparklers take the sob size into account now, when available (Had to modify husk and spacebase to supply sizes to sparklers, as this was only implemented for explosions.).

Ok that's me for today, catch you next time on BlindSide Development Log! :P

[Pip Comment] - ''I think we should open this log to everyone BS, what do you think?''

[BlindSide's response] - ''BlindSide's Star Sonata Development log grand opening! I like the sound of that. (I also like the sound of my own voice, lol)''

== May 17th ==

I spent more time fixing wormholes and a few other things today. I made a small video showing the two seperate parts of a wormhole, they are combined in the final product: http://irrlichtirc.g0dsoft.com/BlindSide/wh.wmv

Anyway enough about that, I added a cool bulge to lasers:

[[Image:LaserBulge.jpg]]

Particle effects:

[[Image:LaserParticle.jpg]]

Custom core textures:

[[Image:LaserYingYang.jpg]]

== May 16th ==

Something was annoying me about the last screenshot, it's the hard end that the lasers have, it looks very unprofessional (Like the C1 lasers :P, not baggin' on C1 or anything). I scratched my head for some time on how to get rid of this without resorting to to textures (Which means scrapping the whole geometry idea and starting from scratch). Solution: More geometry! I think I am getting better at writing meshes by hand. Mind you I only added 3 vertices, but the end result speaks for itself:

[[Image:LaserDev7.jpg]]

Now to add some more variation as promised!

== May 14th ==

Lasers of course should have an overly bright bit in the center, so with some more hacking I got this:

[[Image:LaserDev6.jpg]]

Note that I don't use any textures for this, the laser is purely geometry and the color variation is from blending the vertex colors. This should in theory prove more efficient than a texture based solution, and more importantly it allows us to set any arbitary colors we want without extra hassle.

== May 13th ==

Finally it is lasers time! Lasers are certainly one of the more interesting graphics elements. Few methods/variations arise:

- Criss cross 2 billboards to create a beam effect, fairly simple.

No textures are needed here as we can just 2 more vertices and interpolate the vertex color from black at the edges to whatever the color is in the center.

- I could place one or two of those billboard volume light scene nodes on
the beam to create a bit more variation,

I'm always meaning to use them somewhere but haven't found the place.

- A better idea would be to just use an elongated sphere and only render
the bumps/animations on the lasers in the glow pass.

This should create a nice effect, I will probably try this method first.

- For wide area laser/tractory type things a cone with scrolling textures
(Via texture matrices would be appropriate).

I will probably just use whatever texture is provided with C1 and scroll that along the 3 dimensional cone, should come out nice.

Well I am off to implement them and will hopefully have some screenshots in a few hours!

(Some time passes)

Ok, first of all, lets get acquainted with the Laser space objects. Process the start and endpoints and draw a simple line for debug output:

[[Image:LaserDev1.jpg]]

Oh dear that does not look right. Oh yes! The laser is using relative coordinates. Subtract that laser's position from the endpoint:

[[Image:LaserDev2.jpg]]

That's more like it!

Now let's make it look more like a laser. After a bit of magic (And a complete re-write of an already available laser scene node for Irrlicht), we get something like this:

[[Image:LaserDev3.jpg]]

Now that's starting to look more like a laser! Let's try some glow and see what we get:

[[Image:LaserDev4.jpg]]

OK, maybe that's a little too much glow! Let's reduce the laser's radius when applying glow:

[[Image:LaserDev5.jpg]]

It's getting better! Next time we'll try adding a green light to the front of the ship when it fires a laser (Other surprises are in store!). That's all for today, stay tuned.

[Pip Comment] - ''Starting to look very nice. Any way to add a bit of variation up and down the beam?''

[BlindSide response] - ''Thanks for your comment pip! The lasers will indeed get some variation once the basic look is perfected.''

== May 12th ==

I've been improving the background generation on/off. On my Phenom 9950 system (2.6 ghz, Only using one core):

- Low/Medium settings take 60 milliseconds to generate the background nebula.
- High+ settings take ~400 milliseconds to generate the background nebula.

I may consider moving this to the gpu for better performance, as high settings systems will undoubtedly support this functionality (I would use the same code that creates the animated patterns on the suns, so it should be pretty damn fast). We'll see.

Currently the background is placed on a flat billboard but I am considering moving this to a hemisphere/quarter-sphere(?) to create a more 3 dimensional feeling.

[Smiley Comment] ''I assume the background will be the same each time you visit the same galaxy, correct? Its just generating the SAME nebula based on parameters set at universe creation, correct? I think the galaxies should keep their "look" from visit to visit.''

[BlindSide reply] ''Thanks for the comment Smiley! That is correct, the nebula generator currently uses the galaxy id as the seed for the generation, so visiting the same galaxy twice would give you the same look and colors. ''

[[Category:Client_2_Dev]]

BlindSide Log

2009-05-24T06:04:46Z

BlindSide: /* May 23rd */

= BlindSide's Star Sonata Development Journal =

== May 23rd ==

More work on per-pixel lighting today. For those who know a thing or two about lighting mathematics, I scrapped the traditional attenuation formula for a simple (1.0 - distance / radius), works much better now. I also had a play around with a rim light (Originally intended for planet atmospheres but I think it tends to look nice on ships too.). A rim light is the fading white outline you see in the following image:

[[Image:RimLight.png]]

Believe it or not, there's still no bump mapping in that shot. Then again, I reckon that bumpmapping will have a more noticeable effect on things like planets and bigger ships. I'll hack that in and report back.

== May 21st ==

Today I started on per-pixel lighting. I am supposed to go ahead and implement bumpmapping, rim lighting, and whatever effects I feel like stuffing in the shader to make it look pretty.

Now, what is per-pixel lighting? Let's start with a brief explanation:

In legacy graphics, lighting is calculated on a per-vertex level, for example, for your standard n dot l (normal dot product light direction) style lighting, it would be calculated for each vertex, based on the vertex normal, and then interpolated across the triangle. It typically produces ugly triangle shaped artifacts in under tessellated models (Models with a small amount of triangles).

Something like this (Images thanks to LightHouse3d):

[[Image:PointGL.gif]]

Per-pixel on the other hand, performs the operation on every pixel, without the need to interpolate the final result across the triangle. It's typically more computationally expensive, but the results speak for themselves:

[[Image:PointPix.gif]]

Here is a side by side comparison of just ordinary lighting applied to a Zebu (No bumpmaps). The one on the left is per-pixel and the one on the right is fixed function per-vertex lighting. Particularly near the cockpit you can make out how the per-pixel lighting approach produces a more distinct result, where as the lighting on the per-vertex version looks rather vague:

[[Image:ZebuPerPix.jpg]]

Please note that the per-pixel version is using slightly different material settings and therefore it is slightly darker.

Also, earlier in the forums I posted up a screenshot of the pax frigate. I think this is one of the ships that benefit the most in particular from per-pixel lighting. With the same viewing angle and position, this is the old shot:

[[Image:OldPaxFrigate.jpg]]

And this is the new (Note this was taken on Very High so it has anti-aliasing applied too unlike the old shot):

[[Image:NewPaxFrigate.jpg]]

That's all for today, folks.

== May 19th ==

Added quite a few things since the last post, namely lightning style lasers. Jade Ion is now a combination of animated lightning and beam rather than a static custom image. I would post a screenshot but it won't do it justice, better to see it moving. Some lightning style lasers such as Really Big Laser are using pure lightning, and stuff like shield transference still use a static core texture (Screenshot in last post).

On the lasers side I've also added some particles that emit from the firing point to create a sort of muzzle effect. Will need to test this with really big lasers (I don't specifically refer to Really Big Laser here).

For explosions, I enhanced the look by using a seperate particle texture (And system), and made them only refract on ships. Sparklers take the sob size into account now, when available (Had to modify husk and spacebase to supply sizes to sparklers, as this was only implemented for explosions.).

Ok that's me for today, catch you next time on BlindSide Development Log! :P

[Pip Comment] - ''I think we should open this log to everyone BS, what do you think?''

[BlindSide's response] - ''BlindSide's Star Sonata Development log grand opening! I like the sound of that. (I also like the sound of my own voice, lol)''

== May 17th ==

I spent more time fixing wormholes and a few other things today. I made a small video showing the two seperate parts of a wormhole, they are combined in the final product: http://irrlichtirc.g0dsoft.com/BlindSide/wh.wmv

Anyway enough about that, I added a cool bulge to lasers:

[[Image:LaserBulge.jpg]]

Particle effects:

[[Image:LaserParticle.jpg]]

Custom core textures:

[[Image:LaserYingYang.jpg]]

== May 16th ==

Something was annoying me about the last screenshot, it's the hard end that the lasers have, it looks very unprofessional (Like the C1 lasers :P, not baggin' on C1 or anything). I scratched my head for some time on how to get rid of this without resorting to to textures (Which means scrapping the whole geometry idea and starting from scratch). Solution: More geometry! I think I am getting better at writing meshes by hand. Mind you I only added 3 vertices, but the end result speaks for itself:

[[Image:LaserDev7.jpg]]

Now to add some more variation as promised!

== May 14th ==

Lasers of course should have an overly bright bit in the center, so with some more hacking I got this:

[[Image:LaserDev6.jpg]]

Note that I don't use any textures for this, the laser is purely geometry and the color variation is from blending the vertex colors. This should in theory prove more efficient than a texture based solution, and more importantly it allows us to set any arbitary colors we want without extra hassle.

== May 13th ==

Finally it is lasers time! Lasers are certainly one of the more interesting graphics elements. Few methods/variations arise:

- Criss cross 2 billboards to create a beam effect, fairly simple.

No textures are needed here as we can just 2 more vertices and interpolate the vertex color from black at the edges to whatever the color is in the center.

- I could place one or two of those billboard volume light scene nodes on
the beam to create a bit more variation,

I'm always meaning to use them somewhere but haven't found the place.

- A better idea would be to just use an elongated sphere and only render
the bumps/animations on the lasers in the glow pass.

This should create a nice effect, I will probably try this method first.

- For wide area laser/tractory type things a cone with scrolling textures
(Via texture matrices would be appropriate).

I will probably just use whatever texture is provided with C1 and scroll that along the 3 dimensional cone, should come out nice.

Well I am off to implement them and will hopefully have some screenshots in a few hours!

(Some time passes)

Ok, first of all, lets get acquainted with the Laser space objects. Process the start and endpoints and draw a simple line for debug output:

[[Image:LaserDev1.jpg]]

Oh dear that does not look right. Oh yes! The laser is using relative coordinates. Subtract that laser's position from the endpoint:

[[Image:LaserDev2.jpg]]

That's more like it!

Now let's make it look more like a laser. After a bit of magic (And a complete re-write of an already available laser scene node for Irrlicht), we get something like this:

[[Image:LaserDev3.jpg]]

Now that's starting to look more like a laser! Let's try some glow and see what we get:

[[Image:LaserDev4.jpg]]

OK, maybe that's a little too much glow! Let's reduce the laser's radius when applying glow:

[[Image:LaserDev5.jpg]]

It's getting better! Next time we'll try adding a green light to the front of the ship when it fires a laser (Other surprises are in store!). That's all for today, stay tuned.

[Pip Comment] - ''Starting to look very nice. Any way to add a bit of variation up and down the beam?''

[BlindSide response] - ''Thanks for your comment pip! The lasers will indeed get some variation once the basic look is perfected.''

== May 12th ==

I've been improving the background generation on/off. On my Phenom 9950 system (2.6 ghz, Only using one core):

- Low/Medium settings take 60 milliseconds to generate the background nebula.
- High+ settings take ~400 milliseconds to generate the background nebula.

I may consider moving this to the gpu for better performance, as high settings systems will undoubtedly support this functionality (I would use the same code that creates the animated patterns on the suns, so it should be pretty damn fast). We'll see.

Currently the background is placed on a flat billboard but I am considering moving this to a hemisphere/quarter-sphere(?) to create a more 3 dimensional feeling.

[Smiley Comment] ''I assume the background will be the same each time you visit the same galaxy, correct? Its just generating the SAME nebula based on parameters set at universe creation, correct? I think the galaxies should keep their "look" from visit to visit.''

[BlindSide reply] ''Thanks for the comment Smiley! That is correct, the nebula generator currently uses the galaxy id as the seed for the generation, so visiting the same galaxy twice would give you the same look and colors. ''

[[Category:Client_2_Dev]]