Thomas Pittman
-
Posts
26 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Thomas Pittman
-
-
It's been a while since we've done an update to pureLIGHT. Fortunately that doesn't mean we've been idle. The last six months have been pretty exciting here at pureLIGHT. The bad news is that we still can't talk about a lot of the really cool things that are happening. The good news is that we have an updated version of pureLIGHT for your enjoyment. Here are the changes for pureLIGHT 1.6.5:
preLIGHT
-Fixed the axis's on ZUp lights imported from Collada
-Default direct/indirect filter radii are now configurable options
-Fixed issues with merging meshes with missing submaterials
-Fixed some minor material import issues from ASE meshes imported from Google Sketchup
-Made some improvements to the LMA unwrapping algorithm, it should produce more efficient unwrappings in some cases now
pureLIGHT
-The live preview lightmaps now have mipmap correction applied to them, preventing some false light bleeds from showing up
-Ability in the ability to render only the lighting on objects
-Fixed some issues resulting from running low on video memory and low on system memory
-Reduced the amount of memory required for baking
-Lightmap updates are delayed slightly to allow them to batch up to prevent the system from becoming unresponsive when baking scenes with lots of small lighting groups
-You can now change the number of lighting threads to be created within pureLIGHT itself, if you don't want to use all of your system resources for a bake
-Fixed some extremely rare cases that could lead to a hot spot texel being generated on the lightmaps
-Splitting a light group with a position offset applied to it now applies that same offset to the split off lights
-You can now move around in lighting preview mode (requires a powerful computer)
-Reconverting a light will now reset its position/direction
The documentation has also been updated to reflect new functionality and interface changes. As always, if there are any questions or concerns or if you just want to make some suggestions or tell us how awesome pureLIGHT is drop us an email at our support address.
-
For our Blender users, we have an updated version of the ASE export script that will work with the new python script plugin system in the 2.5* builds of Blender.
To install and use this script (attached to this post):
1. Copy the script into the Blender addons script directory. (eg: blender-2.57-windows32\2.57\scripts\addons)
2. Open up Blender and go into File -> User Preferences
3. Click on the Import-Export tab
4. Check the box beside Import-Export: ASCII Scene Exporter (.ase)
5. Click Save As Default to always enable this addon
This script will always export just whatever meshes/lights you have selected. Its also a bit nicer than the previous one as it remembers the last file path and stuff like that. However, it is still slightly beta-ish, so, let us know if you run into any difficulties with the script.
-
Also, in my level i got a lot of errors, looking like because there isn't textures.
I wouldn't worry about those warnings, since in your case you know you haven't created any materials.
-
I don't think we have any sample 3d max files available. I'll look into getting one posted up. I'll also pass along your troubles with the spam filter on our support email address.
-
But this would limit me to 60.000 tris because of the format. So I have to split it in some situations.
Plus what about using one texture in several materials? Would your engine load the texture with each material again, or does it check if a texture is loaded already but only change material properties? I hope you know what I mean.
The 60000 tri limit is per-mesh and not per-scene. pureLIGHT itself has no limitations on mesh/scene size (barring physical memory of course).
-
As far as I understand the purelight concept it bakes GI to my models.
The GI seems to be bound to a material.
How does it handle the following scenario:
Let's say I have a small object like a lamp hanging in two rooms.
One room is lit the other one is dark. This would result in two different lightmaps for one object. One dark and one bright.
But as far as I know my lightmap is material bound.
So I would have to
A.) Do a different material for every re-used lamp in my level with a unique lightmap for each lamp. This would be pretty much work for a simple re-used prop plus how would the LE load the texture? Would it load the lightmaps (which is ok) but also load the texture of my lamp over and over again and my Vram will be filled with it?
B.) Don't use Purelight on small objects which would be silly because big objects are also reused, like lets say a pile of crates or palletes in a storage level.
What does Purelight do in such a simple situation? Does it bake all geometry to one or more huge Lightmaps where every lamp-UV will get its own spot?
It depends on how you set your scene up. If each lamp is a seperate object, you will end up with 2 lightmaps and 2 seperate materials (the only difference being the lightmap that they reference). I am assuming that LE will only load the texture on the lamp once (Josh would be the one able to confirm that). Alternatively, if both lamps are the same object they would be baked into a slightly larger lightmap and share the same material.
There's nothing wrong with using pureLIGHT on small objects. You may find it more convenient to group together your small objects into one mesh to bake. Also, really small objects, you are probably better off using vertex-lighting on them (depends on the geometry of the mesh of course).
-
I tried that and it didn't have an effect in the Leadwerks editor.
One thing I just noticed is mesh files in certain directories, are not being updated. Is there an option to make these update in the editor?
The mesh files in these directories, have not updated, while the light maps have:
BoxDemoProject\Module_Common\ExportedLighting
BoxDemoProject\Module_Common\ExportedLighting\Obj
BoxDemoProject\Module_Common\3diobj
This one was updated:
BoxDemoProject\Module_Common\MeshSettings
The mesh files only really store the geometry of the mesh, they don't need to be updated with the exception of saving in vertex colors for VL meshes.
As for the Leadwerks editor and transparency, you'll still have to set that up as you normally would in Leadwerks.
-
I'm having trouble getting the clear areas showing (or not showing) in pureLIGHT. As you can see the spiky bits look right in the Blender render.
http://img691.imageshack.us/img691/5103/cactusalphablender.png
But the black part is not transparent in pureLIGHT.
http://img715.imageshack.us/img715/9018/cactusalphapurelight.png
Has anyone got any ideas? Is it the problem in Blender, or is it something else?
The pureLIGHT preview doesn't show any transparency atm.
If you go into the object's properties and go into its material properties, you can set its transparency type to Alpha to make it transparent to the ray-caster.
-
Yeah as you found this is solved by making the mesh block light on both sides. Chapter 11 in the documentation goes into the exact details on how this works.
The gist of the issue, is that by default only the front faces of a mesh block light. However in a lightmapper, rays are cast from the surface to the light. So the texels on the ground plane inside of the cactus are not blocked by the cactus, making them lit (normally not an issue as you can't see them). What can happen, is the texels that are right on the border of the cactus are partially lit from the inside and partially in shadow on the outside. Setting the mesh to block light on both sides will make the texels on the inside of the ground plane be in shadow as well preventing this light bleed.
-
Is the updated version with the DAE fix out yet?
It should have gone live a few days ago. Are you still having issues with DAE files?
-
Not sure if this feature exists, but I can't find it. A "Jump to model" feature would be very handy for this program.
When you have something selected, if you press F, it'll jump the view to looking at the mesh/light.
-
Thanks for your response. I have to dig deeper into it but need to finish two jobs before.
All I did was to export a scene into one .ase, saved out the scene in prelight, loaded in purelight and only got a grey viewport without anything in it.
Before using .ase i tried .dae three times which gave me loading errors in prelight.
All in all Purelight seems to be very well documented so I don't want to call it bad. I just need some more time.
Hmm, we can investigate the dae errors for you if you send one of the affected meshes to support@purelighttech.com. What 3d Modelling program/exporter are you using to generate the dae files?
If you just have a grey viewport, its possible that your mesh is just located far away from the camera. Does it show up under the meshes menu at the top?
-
I'm still a bit unsure about purelight after playing around with it. It didnt work for me out of the box and seems a bit to confusing in some parts although I'm used to render programs.
But I'll give it some more tries.
If there's anything in particular that is confusing to you, feel free to ask and we can help clear it up for you.
Or feel free to offer suggestions for how to make it work for you.
-
Ah, good news! Would this affect the trial though if i was to re-install the newer version with the fix?
It shouldn't affect the trial at all.
-
I'm Giving the trial a go for this. I'm having some problems with my models though. I normally open my sketchup file in UU3D then export to GMF, so I have been doing this, but exporting to DAE instead. And whenever I start compiling the DAE files in prelight, it crashes and returns this error:
I fixed the problem you were having Richard. We'll have an update up in the near future with the fix. Thanks for sending in the sample mesh.
-
Looks great, but as Laslo already asked, what's the deal with terrain ... is this just for indoor scenes and can't be used for external global lighting?
For terrain, unless you turn your terrain into a mesh that pureLIGHT can read in, then, no, you can't use it for terrain. There's also no standard for representing terrain between various game engines.
Probably the easiest way to use it on a Leadwerks terrain, would be to bake the terrain as a giant vertex-lit mesh, and then merge the lighting data in with the terrain height field.
Generally speaking, lightmapping works best with interior scenes. Exterior scenes tend to just be dominated by a single directional light.
-
I really think it should have been an add-on that could have been incorporated into the Leadwerks editor. I'd really like to use this for my project, and I think it would really suite it. However as it stands, I don't even feel like the added graphical quality is worth the extra time and effort of even using their tools, let alone paying $350 for it.
It just feels like minimum effort was put into this, and they've gone down the route of changing things just enough so it becomes possible to use it with Leadwerks, but not actually worried about it being easy and convenient to do so.
That would be the ideal situation.
-
I'm Giving the trial a go for this. I'm having some problems with my models though. I normally open my sketchup file in UU3D then export to GMF, so I have been doing this, but exporting to DAE instead. And whenever I start compiling the DAE files in prelight, it crashes and returns this error:
Problem signature: Problem Event Name: CLR20r3 Problem Signature 01: prelight_trial.exe Problem Signature 02: 3.5.3854.15073 Problem Signature 03: 4c4710b2 Problem Signature 04: System.Xml Problem Signature 05: 2.0.0.0 Problem Signature 06: 4a275e0f Problem Signature 07: 437 Problem Signature 08: 2a Problem Signature 09: System.Xml.XmlException
There is a workaround for this, but it involves me opening my sketchup file in UU3D, exporting to 3ds. Opening that 3ds file in blender, then exporting to DAE. I'm not happy doing it this way either as it uses up too much time.
Using the ase plugin for UU3D allows the file to compile but returns an error in the app, which is as follows:
"LMA_1.ase ERROR: Lightmap too large(larger than 4096x4096)"
Any help would be much appreciated.
Thanks.
Could you email us an example DAE file from sketchup that isn't working? support@purelighttech.com will get it to us.
The lightmap size message is cause either your texel size is far too low, or your mesh is really large and complex resulting in a lightmap that exceeds the maximum size that you have set (this can be changed in the preLight options).
-
The trial version expiration issues should be fixed now, and the trial version should work on Windows Xp now as well. Just download the updated version from our website and it should work fine.
Sorry for the inconvenience, we should have tested the trial version out on Xp first (I know I tested the full version on Xp).
-
Well, you can use GetDynamicTimeZoneInformation when the OS is Vista or up, and use POSIX calls for all other OS (which would be XP/WINE only anyway). Most users still have XP, so I think it's a good idea to support it (source: http://www.netmarketshare.com/os-market-share.aspx?qprid=11 ).
We do support Xp, its only the trial version that is busted under Xp. I'll have a fix for this up shortly.
-
Why does pureLIGHT need time zone information anyway? Can't it just read the system time using POSIX compliant C functions in time.h? I've replaced also all Windows specific file system and OS calls with POSIX calls, so that I can compile my programs on all platforms.
They are buggy under some locales and operating system combinations. The only call I've ever seen that works right under all circumstances is the GetDynamicTimeZoneInformation call.
-
It seems pureLIGHT does not work on Windows (XP), but only on Vista and 7.
I get this error when starting it:
And Microsoft says GetDynamicTimeZoneInformation is only available in Vista and up:
http://msdn.microsoft.com/en-us/library/ms724318%28VS.85%29.aspx
Hmm interesting. I really, really hate the way Windows deals with time reporting.
The trial expiration thing is a weird issue that sometimes crops up and we're not entirely sure why. I think its related to some combination of operating system version, time zones and localization settings. If you are experiencing this, if you could let us know these pieces of information.
Generally, the issue seems to correct itself after a day, which is weird.
-
My understanding is that the benefit of using pureLIGHT over other raytracers is the speed, quality and short (and especially integrated, which apparently will be still more tight in future) pipeline between LE and pureLIGHT. It might be well worth the money then, although I'd be more willing to pay if there was a Linux version planned too, since I'm running XP and might need more RAM some day.
There are no plans at this time for a non-Windows version.
-
Hello everyone, I'm the lead programmer on the pureLIGHT team. Let me clear up a few things in this thread (and a few others):
-pureLIGHT will be available sometime in the next few days. We have to set a few things up on our end first.
-pureLIGHT itself is a seperate program from Leadwerks. They are not integrated at this time.
-Using these features are quite simple. The colored shadows are simply a toggle in the light properties inside of Leadwerks, and a lua script that gets attached to the shadow-casting mesh. Bringing in a scene from pureLIGHT to Leadwerks is as simple as a menu click, it will setup all of the materials automatically for you. We also only merge in changes to the sbx and material files, we won't overwrite any changes that you have made afterwards inside of Leadwerks.
-Current supported import file formats are Collada and ASE, FBX isn't supported at this time.
-There is nothing stopping you from using any lightmapper that you want with Leadwerks. We offer quality, speed, an iterative bake process (no waiting hours before you can preview your lighting), indirect-only options, a powerful unwrapper, an easy workflow (pureLIGHT was created partially in response to how time-consuming baking lightmaps in 3d max was for us), and 1-click exporting/importing into Leadwerks. We're also considerably cheaper than other commercial lightmappers. Give our 30 day evaluation version a try. I think you will be happy with our product.
-You could probably figure out a way of bringing a Leadwerks scene into pureLIGHT. If there is enough demand, I may be able to work out something to do this for you.
-We have a very thorough manual and an extensive set of youtube tutorials http://www.youtube.com/user/pureLIGHTTech on how to use pureLIGHT itself.
Plugins
in Suggestion Box
Posted
I've written plugins in the past for 3d Max, and it has a very powerfull system in place for extending what it can do. Having a general read through/overview of how it does things could give you some ideas: http://docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-SDK-Programmer-Guide/files/GUID-717D0F11-78F1-4C0E-878F-506A31911E4D.htm
Each plugin dll starts by describing what it is (a new modifier, a general utility, a new material type, a new texture format importer/exporter, etc). So you can tell max that you are a texture import plugin, which then extends the BitmapIO parent class, tells max what file extensions it handles, and implements functions for reading the texture data into Max's internal bitmap structures. Or you can tell max that you are a modifier plugin, which extends the Modifier class and implements functions that describe what types of data on a mesh it changes and a function for applying that modification.
Everything has unique ID numbers, letting you do things like subclass their built-in objects and let Max still instantiate them via a factory mechanism. Then you can extend the functionality of anything in the program. Similarly, its got formalized ways of storing parameters, retrieving parameters, blocks of data, etc, so that they can be shared between plugins with no knowledge of each other's internal workings, and to get automatically saved into the scene file. Be sure to give the plugin users a Load/Save function that lets them store any data that they want, and if you are saving plugin data inside of the Leadwerks map files, be sure to always record in version information of the plugin and what plugin it came from so that it can be ignored/handled gracefully if the plugin isn't present.
It also lets you create your own interface panels and such inside of 3d Max, and ties you into their windows message loop, so any keyboard/mouse/gui functionality can be done (you just have to pay attention to whether or not the plugin indicates that they processed the message or not). There's also formalized systems for registering your plugin's functions for keyboard hotkeys and to be able to be put into the menus/toolbars. They also have a more specialized event notification system, letting you register a function for when the scene is saved, loaded, changed, etc in various ways.
You get at most of the scene data by calling a global function that gives you a pointer to all of the scene data, letting you access just about anything you want (all nodes, meshes, lights, material libraries, shaders, etc).
For Leadwerks, a plugin could also indicate whether or not it should be loaded just in editor mode or just in game mode, and there should be a flag somewhere indicating what the current state of Leadwerks is. There's no need for something like a texture importer plugin to be active outside of the editor, as it will have already converted the textures into Leadwerk's native texture format long before the end user playing the game sees the data. A pathfinding plugin would need to create additional tools in the editor to configure it, and only the actual pathfinding code to be active when in game.
This is just one possible way of doing it, might be overkill for a game engine.