Thomas Pittman

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.

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. io_export_ase.zip

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.

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).

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).

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.

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.

It should have gone live a few days ago. Are you still having issues with DAE files?

When you have something selected, if you press F, it'll jump the view to looking at the mesh/light.

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?

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.

It shouldn't affect the trial at all.

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.

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.

That would be the ideal situation.

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).

We do support Xp, its only the trial version that is busted under Xp. I'll have a fix for this up shortly.

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.

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.

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.