Elendir on 26/1/2011 at 12:39
Version 0.0.4 is ready for download.
A brief description of what's new:
* Dark Exporter is now able to detect some user errors in Blender, like the meshes without any materials. It signals it with appropriate message. More on that in project's blog.
* New function - transparency
* New toggle button in the configuration window. It controls whether transparency discovery should be enabled.
* New debug level. The 5th level displays transparent materials summary.
As usually two important links:
Project's site: (
https://sourceforge.net/projects/darkexporter/) https://sourceforge.net/projects/darkexporter/
Project's blog: (
https://sourceforge.net/apps/wordpress/darkexporter/) https://sourceforge.net/apps/wordpress/darkexporter/
Elendir on 28/1/2011 at 11:19
I've done some tests with self-illumination, as this is something I currently work on for Dark Exporter.
Looks like that Unknown value (as NV used to call it) doesn't affect self-illumination nor transparency. I've tested several different values and the output 3D object looks exactly the same each time.
Off course it doesn't mean that value is of no significance. Maybe some specific value has an influence on self-illumination or transparency or something else. For now however I'll stick to the Blender's zero.
Elendir on 1/2/2011 at 12:45
During my work on Dark Exporter I found out a strange phenomenon I called briefly "a temporary material". It's related to the Blender's native 3DS export plugin and affects any object exported to 3DS format.
Some of you may already know that it's a historical limitation of 3D Studio format.
I've described the problem in details on my developer blog. It may be interesting for some of you, especially because it influences Dark Exporter as well.
(
http://sourceforge.net/apps/wordpress/darkexporter/2011/02/01/temporary-material-a-full-story/) The full story is here....
Elendir on 3/2/2011 at 11:15
Hi all,
Next version 0.0.5 is ready for download from (
http://sourceforge.net/projects/darkexporter/) Sourceforge.
This version includes a couple of minor updates and one new function of detecting of self-illuminated materials.
Plugin is still in Alpha, but from the functional point of view it offers everything I wanted it to have.
Now it requires plenty of real tests, i.e. creating models for a Thief mission. This is what I'm gonna do in the upcoming months. After that I plan to release the 0.1.0 beta (hopefully with a decent documentation).
Details of the current 0.0.5 version as usually on the (
http://sourceforge.net/apps/wordpress/darkexporter/) dev blog...
See you!
Neb on 10/2/2011 at 12:16
It seems to be working for Thief 2 so far. I tried out the default cube and then Suzanne.
I'll play around some more.
(Good work. :D )
Elendir on 13/4/2011 at 09:20
I've started writing a documentation of the Dark Exporter plugin some time ago and during my work I discovered the following odd behavior of the rendering system in Dark Engine 1.
Take a look at the below comparizon of a simple window object I plan to include in the manual:
Inline Image:
http://dl.dropbox.com/u/12017775/porownanie1.jpgThe object is intentionaly simplified for the purpose of the manual. It's consisted of 4 distinct objects in Blender namely: Glass, Frame, and Vert, Horiz (the latter two create horizontal and vertical part of the inner cross of the window).
The Glass object is a plane with self transparency applied and it's double sided. As you can see on the left part of the screenshot when the camera looks at the front of the window the transparent glass shows the other half of the frame. On the right screenshot the camera looks from the other side of the object. Looking from this direction the transparency works a bit odd, because I cannot see the remaining part of the window frame, that should be visible through the glass.
It suspect it may be caused by normal vector direction, but I'm not sure. Maybe some of you have faced a similar problem?
Elendir on 13/4/2011 at 10:31
OK, I've just figured it out by myself. It's an interesting discovery, since it answers the question I put here in the thread a while ago.
I turns out that the unknown value I mentioned a few posts earlier is exactly the source of the problem! In my case it's always zero and I let that value to stay like that, because I haven't noticed any influence of that value upon the objects in Game Mode.
I manually changed that value to 1 and now the object looks perfectly from each side. Here is the full example (look at the line refering to transparent material:
Code:
COMMENT{
// Converted by 3ds2e from: okno1 - Modified by Dark Exporter 0.0.5a
}
MATERIALS{
1,"MyMaterial",PHONG,RGB 204,204,204,TRANSP 0;
2,"MyMaterialWD",PHONG,TMAP "WDPLNK.gif",0,TRANSP 0;
3,"GlassMatCRAC",PHONG,TMAP "CRACK.gif",0,TRANSP 56,DBL;}
to
Code:
COMMENT{
// Converted by 3ds2e from: okno1 - Modified by Dark Exporter 0.0.5a
}
MATERIALS{
1,"MyMaterial",PHONG,RGB 204,204,204,TRANSP 0;
2,"MyMaterialWD",PHONG,TMAP "WDPLNK.gif",0,TRANSP 0;
3,"GlassMatCRAC",PHONG,TMAP "CRACK.gif",1,TRANSP 56,DBL;}
From now on I know that this unknown value should be 1. Still don't know however why this option (0 or 1) is offered to the users? Maybe it improves the display performance? Don't know...
SOLVED!
Elendir on 13/4/2011 at 11:45
Quote Posted by Elendir
OK, I've just figured it out by myself. It's an interesting discovery, since it answers the question I put here in the thread a while ago.
I turns out that the unknown value I mentioned a few posts earlier is exactly the source of the problem! In my case it's always zero and I let that value to stay like that, because I haven't noticed any influence of that value upon the objects in Game Mode.
I manually changed that value to 1 and now the object looks perfectly from each side. Here is the full example (look at the line refering to transparent material:
Code:
COMMENT{
// Converted by 3ds2e from: okno1 - Modified by Dark Exporter 0.0.5a
}
MATERIALS{
1,"MyMaterial",PHONG,RGB 204,204,204,TRANSP 0;
2,"MyMaterialWD",PHONG,TMAP "WDPLNK.gif",0,TRANSP 0;
3,"GlassMatCRAC",PHONG,TMAP "CRACK.gif",0,TRANSP 56,DBL;}
to
Code:
COMMENT{
// Converted by 3ds2e from: okno1 - Modified by Dark Exporter 0.0.5a
}
MATERIALS{
1,"MyMaterial",PHONG,RGB 204,204,204,TRANSP 0;
2,"MyMaterialWD",PHONG,TMAP "WDPLNK.gif",0,TRANSP 0;
3,"GlassMatCRAC",PHONG,TMAP "CRACK.gif",1,TRANSP 56,DBL;}
From now on I know that this unknown value should be 1. Still don't know however why this option (0 or 1) is offered to the users? Maybe it improves the display performance? Don't know...
SOLVED!
Ups... Sorry guys! It's been too early to announce that :tsktsk:
After further examination I found out that The Unknown Value is not the reason of the problem. Nevertheless the issue is solved, because I think I found the true source of the problem, and it's easy to resolve it. The bsp.exe has a special option -l(0,1,2,3). By default bsp.exe uses -l3 (an optimization algorithm). This feature is included in Dark Exporter 0.0.5a and set to -l0, since it often produces smaller file sizes.
I didn't know that this feature may have an impact on the double-sided and transparent materials when camera doesn't face normal vector of such surfaces.
So to solve the described issue the user can simply change bsp_optimisation to 3 in the configuration window of the script.
Additionally after many tests I can confirm that only -l0 option reproduce this strange behaviour. Options -l1, -l2 and -l3 don't seem to have any influence on the output object.
SOLVED!
