Jump to content

Thomas Pittman

  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About Thomas Pittman

  • Rank

Profile Information

  • Gender
  1. 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.
  2. 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.
  3. 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
  4. I wouldn't worry about those warnings, since in your case you know you haven't created any materials.
  5. 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.
  6. 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).
  7. 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).
  8. 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.
  9. 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.
  10. 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.
  11. It should have gone live a few days ago. Are you still having issues with DAE files?
  12. When you have something selected, if you press F, it'll jump the view to looking at the mesh/light.
  13. 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?
  14. 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.
  15. It shouldn't affect the trial at all.
  • Create New...