PyroEditor - Radical Source

Anything and everything that's related to OGRE or the wider graphics field that doesn't fit into the other forums.
Krulspeld
Kobold
Posts: 35
Joined: Tue Apr 05, 2005 9:51 pm

Post by Krulspeld » Mon May 09, 2005 10:02 am

Falagard,

here's my answer to some of your questions
For example, imagine I had a 1600 square foot home I wanted to lightmap, with three stories. Would it be able to handle that sort of thing?
I believe so.
As far as I know, OgreFSRad only supported point lights, and possibly mesh lights (geometry that acts as a light - probably by sampling points across the surface of the mesh?)
It's been a while since I took a look at the OgreFSRad and I believe there is a point light converter in there. However FSRad's strongest feature is using geometry as light and I don't remember if OgreFSRad supports this.
when you send geometry to OgreFSRad to lightmap, do you get back different geometry (different number of vertices, new UV coordinates obviously for the lightmaps?)
FSRad may slice your data to fit an octree data structure, but this can be turned off. Furthermore because FSRad can generate multiple lightmaps for one piece of geometry your original geometry may be return separated. Besides that all sets of connected triangles will be clipped against the lightmap size to make sure the fit in a lightmap. So what you will get back are new UV coordinates and possibly new vertices.
If it gives you back geometry, does it contain the original UVs and a second set of UVs so you can use the geometry that came back from OgreFSRad in place of your original geometry?
FSRad will store your original UV's and give them back next to the generated lightmap UV's, but remember that only one set of original UV's can be stored.
Can you give it a lightmap texture size and it generate all lightmaps within that limit, or does it simply start creating lightmap textures on its own and spreading them out over multiple textures without you having a say in it?
Unfortunately the latter is the case. You define the number of pixels per meter and FSRad will make sure it generates enough lightmaps to fit all geometry. The lightmap packing could be more optimized, because for instance triangles with large aspect ratios will often end up in a new lightmap.

One of the strong features of Gile[s] is that it creates lightmaps attached to materials. With FSRad you may end up with a lot of extra stateswaps, because of the distribution over multiple lightmaps. Besides that FSRad does not support transparency/translucency like Gile[s] does. It does however in my opinion calculate a more physically plausible result.
0 x

User avatar
psyclonist
OGRE Expert User
OGRE Expert User
Posts: 286
Joined: Fri Nov 01, 2002 3:54 pm
Location: Berlin & Nuremberg, Germany
Contact:

Post by psyclonist » Mon May 09, 2005 11:39 am

Krulspeld wrote: It's been a while since I took a look at the OgreFSRad and I believe there is a point light converter in there. However FSRad's strongest feature is using geometry as light and I don't remember if OgreFSRad supports this.
OgreFSRad has a point light converter which simulates point lights by creating a simple mesh. It works pretty good.
Krulspeld wrote:
If it gives you back geometry, does it contain the original UVs and a second set of UVs so you can use the geometry that came back from OgreFSRad in place of your original geometry?
FSRad will store your original UV's and give them back next to the generated lightmap UV's, but remember that only one set of original UV's can be stored.
No, OgreFSRad preserves all existing UV coordinate sets and adds a new set of UVs for the lightmaps. Thus, for example, existing materials referencing a specific uv set continue to work without problems.

Note: At the moment, the CVS version of OgreFSRad is being updated and may not produce the desired results all the time. I'm working on a scene editor which also provides a front end for OgreFSRad. (realtime lit / gourad: before; lightmapped without smoothing groups: after).
Krulspeld wrote:One of the strong features of Gile[s] is that it creates lightmaps attached to materials. With FSRad you may end up with a lot of extra stateswaps, because of the distribution over multiple lightmaps. Besides that FSRad does not support transparency/translucency like Gile[s] does. It does however in my opinion calculate a more physically plausible result.
Translucency: Shouldn't be too hard to add ;) After all, fsrad is written pretty cleanly.
Texture Maps / State swaps: Both approaches have advantages and disadvantages in certain situations. Using a good value for the texel size (in world coordinates) to minimise state changes without degrading quality too much is critical, of course. And doable.

-psy
0 x

Krulspeld
Kobold
Posts: 35
Joined: Tue Apr 05, 2005 9:51 pm

Post by Krulspeld » Mon May 09, 2005 3:35 pm

OgreFSRad has a point light converter which simulates point lights by creating a simple mesh. It works pretty good.
True, but since pointlights do not exist in real life it's more realistic to add lights as geometry. The point lights in OgreFSRad are added with an area of zero, which will result in hard shadows.
No, OgreFSRad preserves all existing UV coordinate sets and adds a new set of UVs for the lightmaps. Thus, for example, existing materials referencing a specific uv set continue to work without problems.
I drew my conclusions based on experience with FSRad and not OgreFSRad. In FSRad only two sets of texture coordinates are supported.
However looking at the source code of DotSceneConverter.cpp currently in CVS it seems that multiple UV-set support in convertNodeToFSRad is commented out.
Translucency: Shouldn't be too hard to add Wink After all, fsrad is written pretty cleanly.
The problem is that FSRad only works with geometry for lighting. It does not look at the texture that is applied to an object. So you might be able to achieve transparency/transluceny on a geometry level, but geometry with alpha masked textures (like commonly used for grass, trees, fences etc.) and translucent textures (like stained-glass windows) will have no effect in FSRad.
0 x

User avatar
psyclonist
OGRE Expert User
OGRE Expert User
Posts: 286
Joined: Fri Nov 01, 2002 3:54 pm
Location: Berlin & Nuremberg, Germany
Contact:

Post by psyclonist » Mon May 09, 2005 4:39 pm

Krulspeld wrote:The point lights in OgreFSRad are added with an area of zero, which will result in hard shadows.
Err, no hard shadows here. Not with my copy, anyway :) Did you actually give them a try? I'll have to check the version in the OgreAddons repository. Maybe the correct point light conversion code didn't make it in.
Krulspeld wrote:I drew my conclusions based on experience with FSRad and not OgreFSRad. In FSRad only two sets of texture coordinates are supported. However looking at the source code of DotSceneConverter.cpp currently in CVS it seems that multiple UV-set support in convertNodeToFSRad is commented out.
I said that it's currently WIP, as compatibility was broken between Ogre releases. It's being worked on and only very small changes are necessary to reactivate this feature. (Btw, the internal FSRad code supports multiple texture coordinate sets even though the original oct format didn't, IIRC.)
Krulspeld wrote:The problem is that FSRad only works with geometry for lighting. It does not look at the texture that is applied to an object. So you might be able to achieve transparency/transluceny on a geometry level, but geometry with alpha masked textures (like commonly used for grass, trees, fences etc.) and translucent textures (like stained-glass windows) will have no effect in FSRad.
I know what translucent textures are ;) Nevertheless, it's possible to add this to fsrad without much hassle. It supports per poly material ids and adding texture lookups isn't too difficult.

-psy
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Post by jacmoe » Mon May 09, 2005 6:10 pm

You guys are really hi-jacking necromancers! :)
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
DarkSeraph
Halfling
Posts: 85
Joined: Thu Apr 28, 2005 5:42 pm

Post by DarkSeraph » Mon May 09, 2005 6:37 pm

This thread has been way hijacked, but while we're on the subject, what file format does FSrad take in?
0 x

User avatar
psyclonist
OGRE Expert User
OGRE Expert User
Posts: 286
Joined: Fri Nov 01, 2002 3:54 pm
Location: Berlin & Nuremberg, Germany
Contact:

Post by psyclonist » Mon May 09, 2005 7:12 pm

DarkSeraph wrote:This thread has been way hijacked, but while we're on the subject, what file format does FSrad take in?
The original fsrad uses oct and ase. But OgreFSRad uses .scene and .mesh. What else did you expect? :)

-psy
0 x

Krulspeld
Kobold
Posts: 35
Joined: Tue Apr 05, 2005 9:51 pm

Post by Krulspeld » Mon May 09, 2005 10:18 pm

psyclonist wrote:
Krulspeld wrote:The point lights in OgreFSRad are added with an area of zero, which will result in hard shadows.
Err, no hard shadows here. Not with my copy, anyway :) Did you actually give them a try? I'll have to check the version in the OgreAddons repository. Maybe the correct point light conversion code didn't make it in.
Here's an example of what I consider to be hard shadows. FSRad was used with the "direct light only" option. Though not using OgreFSRad my tool uses pointlights like the ones supported in OgreFSRad.
Image
The only softness we see is due to texture filtering.
Krulspeld wrote:I drew my conclusions based on experience with FSRad and not OgreFSRad. In FSRad only two sets of texture coordinates are supported. However looking at the source code of DotSceneConverter.cpp currently in CVS it seems that multiple UV-set support in convertNodeToFSRad is commented out.
I said that it's currently WIP, as compatibility was broken between Ogre releases. It's being worked on and only very small changes are necessary to reactivate this feature. (Btw, the internal FSRad code supports multiple texture coordinate sets even though the original oct format didn't, IIRC.)
psyclonist wrote:
Krulspeld wrote:The problem is that FSRad only works with geometry for lighting. It does not look at the texture that is applied to an object. So you might be able to achieve transparency/transluceny on a geometry level, but geometry with alpha masked textures (like commonly used for grass, trees, fences etc.) and translucent textures (like stained-glass windows) will have no effect in FSRad.
I know what translucent textures are ;) Nevertheless, it's possible to add this to fsrad without much hassle. It supports per poly material ids and adding texture lookups isn't too difficult.
Sure per poly translucency should be easy, but how would you apply textures to your light emitting or transmissive patches? Either by taking an average of the texels covering you patch or by splitting up your geometry into patches of texel size. Well, maybe the first solution is the easiest one.

As for the missing support for smoothing groups as mentioned earlier in this thread. Do you have a solution for this?

BTW is there an official specification document that describes the dotscene format?
0 x

User avatar
psyclonist
OGRE Expert User
OGRE Expert User
Posts: 286
Joined: Fri Nov 01, 2002 3:54 pm
Location: Berlin & Nuremberg, Germany
Contact:

Post by psyclonist » Mon May 09, 2005 11:06 pm

I see now what you mean. Smooth shadows in these circumstances are commonly achieved using a few distributed point lights close to each other. Of course, one could automate the generation of these lights using a simple value in .scene...
Krulspeld wrote:As for the missing support for smoothing groups as mentioned earlier in this thread. Do you have a solution for this?
I didn't implement this for now. The reason is that information about smoothing groups isn't contained in .mesh or .scene. How shall ogrefsrad know/detect whether a vertex normal has explicitely been specified or whether it's the result of smoothing?

Why are these questions important? Because ogrefsrad generates geometry if certain conditions are met, i.e. it generates polys. How shall the normals of the new vertices be oriented? We could specify per-mesh, per-entity, per-scene flags... Opinions welcome.
Krulspeld wrote:BTW is there an official specification document that describes the dotscene format?
The DTD is in OgreAddons/dotsceneformat.

-psy
0 x

Krulspeld
Kobold
Posts: 35
Joined: Tue Apr 05, 2005 9:51 pm

Post by Krulspeld » Mon May 09, 2005 11:39 pm

psyclonist wrote:Why are these questions important? Because ogrefsrad generates geometry if certain conditions are met, i.e. it generates polys. How shall the normals of the new vertices be oriented? We could specify per-mesh, per-entity, per-scene flags... Opinions welcome.
I am not sure what you mean by this.

I think I did not pose my question the right way. It's not really a matter of smoothing groups, but of vertex normals instead of face normals. Does OgreFSRad support vertex normals?
psyclonist wrote: The DTD is in OgreAddons/dotsceneformat.
OK, thanks.
0 x

User avatar
psyclonist
OGRE Expert User
OGRE Expert User
Posts: 286
Joined: Fri Nov 01, 2002 3:54 pm
Location: Berlin & Nuremberg, Germany
Contact:

Post by psyclonist » Tue May 10, 2005 12:26 am

Krulspeld wrote:
psyclonist wrote:Why are these questions important? Because ogrefsrad generates geometry if certain conditions are met, i.e. it generates polys. How shall the normals of the new vertices be oriented? We could specify per-mesh, per-entity, per-scene flags... Opinions welcome.
I am not sure what you mean by this.

I think I did not pose my question the right way. It's not really a matter of smoothing groups, but of vertex normals instead of face normals. Does OgreFSRad support vertex normals?
Not out of the box. Ogrefsrad doesn't preserve vertex normals at the moment. Not that it'd be difficult to implement. Again, the reason is that one has to decide how to create the normals for vertices which may be created by fsrad during processing of the scene. We could set to them to the average of the surrounding faces. But that may be wrong in certain situations, depending on the set up of smoothing groups. The information on those is not contained in .mesh, though. So ideally one has to be able to specify it on a per-submesh level. And even better, the exporter should take care of getting the smoothing group information from the modelling application to the data file.

-psy
0 x

Krulspeld
Kobold
Posts: 35
Joined: Tue Apr 05, 2005 9:51 pm

Post by Krulspeld » Tue May 10, 2005 8:12 am

psyclonist wrote:
Krulspeld wrote: I think I did not pose my question the right way. It's not really a matter of smoothing groups, but of vertex normals instead of face normals. Does OgreFSRad support vertex normals?
Not out of the box. Ogrefsrad doesn't preserve vertex normals at the moment. Not that it'd be difficult to implement. Again, the reason is that one has to decide how to create the normals for vertices which may be created by fsrad during processing of the scene. We could set to them to the average of the surrounding faces. But that may be wrong in certain situations, depending on the set up of smoothing groups. The information on those is not contained in .mesh, though. So ideally one has to be able to specify it on a per-submesh level. And even better, the exporter should take care of getting the smoothing group information from the modelling application to the data file.
Ok, it is possible to save vertex normals and come up with a way for creating new normals for newly created vertices. But this is not the actual problem. The lightmaps created by FSRad replace the OpenGL or DirectX lighting so vertex normals are not important anymore after lightmaps are applied. The correct vertex normals should be used in some way by FSRad to calculate correct lighting. Here lies the fundamental problem. FSRad uses face normals to group faces and all primitives represent planar patches which can only be flat shaded due to the mechanisms used in FSRad.
0 x

User avatar
psyclonist
OGRE Expert User
OGRE Expert User
Posts: 286
Joined: Fri Nov 01, 2002 3:54 pm
Location: Berlin & Nuremberg, Germany
Contact:

Post by psyclonist » Tue May 10, 2005 9:27 am

Krulspeld wrote:The lightmaps created by FSRad replace the OpenGL or DirectX lighting so vertex normals are not important anymore after lightmaps are applied.
That's not necessarily true. Event recent games use lightmaps and vertex based lighting at the same time for certain effects.
Krulspeld wrote:fundamental problem
The screenshots I posted were extremely simple ones. I've run it over more complex scenes and the results are usually satisfactory. Also have a look at the levels generated with fsrad based tools (which are available for a variety of engines) and you'll see that it's not a fundamental problem at all (judging by the results). It may be a problem in certain situations, I guess, but I can't really think of one except extremely sparsely tesselated 'organic' models (i.e. lots of 'curved' surfaces). And even then it's not necessarily a problem because the reflected light tends to diffuse the hard edges.

-psy
0 x

Krulspeld
Kobold
Posts: 35
Joined: Tue Apr 05, 2005 9:51 pm

Post by Krulspeld » Tue May 10, 2005 9:58 am

psyclonist wrote: The screenshots I posted were extremely simple ones. I've run it over more complex scenes and the results are usually satisfactory. Also have a look at the levels generated with fsrad based tools (which are available for a variety of engines) and you'll see that it's not a fundamental problem at all (judging by the results). It may be a problem in certain situations, I guess, but I can't really think of one except extremely sparsely tesselated 'organic' models (i.e. lots of 'curved' surfaces). And even then it's not necessarily a problem because the reflected light tends to diffuse the hard edges.
Ok, it will become less visible due to multiple light bounces and areal lights, but essentially all surfaces will be flat shaded. The FSRad screenshots show mainly large planar surfaces. On the ones with a cylinder or a cone you can still see the edges of the surfaces that should have been smooth.
0 x

sgrgc
Greenskin
Posts: 130
Joined: Thu May 12, 2005 1:42 pm

pyroeditor

Post by sgrgc » Thu May 12, 2005 1:49 pm

i have translated most of the code(tooltips and resources) to english.
0 x

User avatar
DarkSeraph
Halfling
Posts: 85
Joined: Thu Apr 28, 2005 5:42 pm

Re: pyroeditor

Post by DarkSeraph » Thu May 12, 2005 3:48 pm

sgrgc wrote:i have translated most of the code(tooltips and resources) to english.
Can you post that somewhere!?!
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Re: pyroeditor

Post by jacmoe » Thu May 12, 2005 7:19 pm

sgrgc wrote:i have translated most of the code(tooltips and resources) to english.
That's definately a good thing! :) I tried to decipher it back then, but gave up. I haven't a Turkish dictionary handy. :wink:
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

sgrgc
Greenskin
Posts: 130
Joined: Thu May 12, 2005 1:42 pm

Post by sgrgc » Mon May 16, 2005 11:40 am

i do not know where i can put it on the net but i can email it to someone
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Post by jacmoe » Mon May 16, 2005 12:06 pm

What is the license on the PyroEditor source?
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

sgrgc
Greenskin
Posts: 130
Joined: Thu May 12, 2005 1:42 pm

Post by sgrgc » Mon May 16, 2005 12:52 pm

0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Post by jacmoe » Mon May 16, 2005 2:29 pm

Then I guess we have to contact the original author?
If he/she is to be found, that is. It's been a couple years since it was written.
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

sgrgc
Greenskin
Posts: 130
Joined: Thu May 12, 2005 1:42 pm

Post by sgrgc » Tue May 17, 2005 11:06 am

http://www.ece.rochester.edu/~harmanci/
E-Mail harmanci at ece dot rochester dot edu
Last edited by sgrgc on Tue May 17, 2005 11:14 am, edited 1 time in total.
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Post by jacmoe » Tue May 17, 2005 11:09 am

Could you send a request mail?
((And remove his e-mail from here - or change it to harmanci at ece dot rochester dot edu))
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
DarkSeraph
Halfling
Posts: 85
Joined: Thu Apr 28, 2005 5:42 pm

Post by DarkSeraph » Thu May 19, 2005 6:26 pm

Since it's GPL and Open Source, can we not just use the source and tweak it a bit to fit Ogre?

I'll email sgrgc when I get home to see if I can get the English copy of this.
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Post by jacmoe » Thu May 19, 2005 6:35 pm

That sounds good.
To me, the PyroEditor looks like WorldCraft (not a bad thing) :wink:
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

Post Reply