tag:blogger.com,1999:blog-105567382024-03-08T15:06:22.861-05:00Valors EndUnknownnoreply@blogger.comBlogger44125tag:blogger.com,1999:blog-10556738.post-72811418070635542712010-10-16T19:27:00.006-04:002010-10-16T19:57:27.686-04:00Long overdue updateIt has been a long time since I have written about the editor. I took a break for a while, not because I wanted to but due to circumstances at work that drained my desire to program. That has been resolved and I have been working steadily on the editor again.<br /><br />I have designed a new content browser that looks eerily similar to Unreal's UDK content browser. Here it is with some sample content shown:<br /><br /><br /><a href="http://2.bp.blogspot.com/_XYu0roVQoVA/TLo2iAhxlPI/AAAAAAAAANE/lFJgBKIVUk0/s1600/009.jpg"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 343px; height: 400px;" src="http://2.bp.blogspot.com/_XYu0roVQoVA/TLo2iAhxlPI/AAAAAAAAANE/lFJgBKIVUk0/s400/009.jpg" alt="" id="BLOGGER_PHOTO_ID_5528791450435818738" border="0" /></a>It does support the same real-time preview when you hover over each item. This helps a lot to identify the correct item before you place it. You can simply drag and drop from here into the scene.<br /><br />The sample content that is visible in the shot is actually from an awesome game made with Ogre called TorchLight. I am simply using their assets for testing purposes since they look really good and are already in Ogre format. I wanted some real data to play with so I also wrote an importer for their levels which show up pretty well in the editor. I am still missing items such as particles, etc but I have the geometry loading so that I can work on my placement tools first.<br /><br /><a href="http://2.bp.blogspot.com/_XYu0roVQoVA/TLo4u2TaIpI/AAAAAAAAANQ/1XflWoWvTB0/s1600/010.jpg"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 400px; height: 247px;" src="http://2.bp.blogspot.com/_XYu0roVQoVA/TLo4u2TaIpI/AAAAAAAAANQ/1XflWoWvTB0/s400/010.jpg" alt="" id="BLOGGER_PHOTO_ID_5528793870052762258" border="0" /></a><br />I also fleshed out the undo/redo system so that every single operation in the editor (even loading a TorchLight level) is now an undoable operation. I do not want a single thing to happen that cannot be undo. I've implemented a History panel so that I can see the actions that were performed as well as what is about to be undone. The following shows the history stack (grows upwards from the bottom) as well as any actions that have been undone in blue.<br /><br /><a href="http://1.bp.blogspot.com/_XYu0roVQoVA/TLo5ZguGk0I/AAAAAAAAANY/j1rNONNm0aQ/s1600/011.jpg"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 387px; height: 376px;" src="http://1.bp.blogspot.com/_XYu0roVQoVA/TLo5ZguGk0I/AAAAAAAAANY/j1rNONNm0aQ/s400/011.jpg" alt="" id="BLOGGER_PHOTO_ID_5528794602993521474" border="0" /></a>I have made a lot of small improvements to the editor such as adding icons to everything, grid snapping, etc. I have also removed every single crash that I have seen to date. I am currently unable to crash the editor and every operation is undoable and redoable which I believe is very important to a good workflow. An editor isn't very good if it crashes on you all the time or if you make a mistake and have to start over.<br /><br />I've also added a simple form of prefabs as well as the ability to clone an existing object in the scene simply by holding the Alt key and translating the object. This makes placing meshes such as floor tiles extremely easy. I will showcase these 2 features in the next video.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-50101368348128681772009-06-03T23:12:00.002-04:002009-06-03T23:16:57.787-04:00Drag and drop materialsKeeping in line with the 'everything is visual' motivation of the editor, I have added the ability to drag and drop materials from the resource browser onto the 3D scene. The materials themselves offer a live preview in the resource browser while the mouse is over it. As it is dragged into the scene, cursor feedback shows when the material can be dropped and when it cannot. I may add the ability to actually live preview it in the scene as well, applying it to the current object that is under the cursor.<br /><br /><a href="http://www.vimeo.com/4992625">View in High-Definition (Recommended)</a><br><br /><a href="http://www.vimeo.com/download/video:3335163?v=2&e=1244088831&h=e5b3e4eebdb12bc9150024ba61035a6e&uh=35b390f75fc216ac9dd07ae287986911">Download Original (3.26 MB)</a><br><br /><object width="400" height="243"><param name="allowfullscreen" value="true" /><param name="allowscriptaccess" value="always" /><param name="movie" value="http://vimeo.com/moogaloop.swf?clip_id=4992625&server=vimeo.com&show_title=0&show_byline=0&show_portrait=0&color=01AAEA&fullscreen=1" /><embed src="http://vimeo.com/moogaloop.swf?clip_id=4992625&server=vimeo.com&show_title=0&show_byline=0&show_portrait=0&color=01AAEA&fullscreen=1" type="application/x-shockwave-flash" allowfullscreen="true" allowscriptaccess="always" width="400" height="243"></embed></object><p><a href="http://vimeo.com/4992625">Material assignment</a> from <a href="http://vimeo.com/shawncarroll">Shawn Carroll</a> on <a href="http://vimeo.com">Vimeo</a>.</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-35348864206361569692009-05-26T22:28:00.004-04:002009-05-26T23:00:58.326-04:00Generalized resource previewI spent a bit of time and have abstracted the resource browser and the thumbnail creator to support any SceneObject instance. All that is required is that a SceneObjectFactory be created that can return the template names of that particular SceneObject type as well as a function that can generate a SceneObject from a template name. The rest is completely generic.<br /><br />Here are particle systems working inside of the resource browser. Now that I have the standalone SceneObjects done, I'll have to support things such as materials that have a 3D representation [a plane with the material on it or sphere or whatever] but aren't directly objects themselves. This will be the second phase of the browser which I will get to later.<br /><br /><a href="http://vimeo.com/4858057">View in High-Definition (Recommended)</a><br><br /><a href="http://vimeo.com/download/video:3096335?v=2&e=1243396810&h=8844f86557cd60f795f5ab2fd4f097ba&uh=9399fb6cbdc2f649199a019dd251465f">Download Original (3.05 MB)</a><br><br /><object width="400" height="240"><param name="allowfullscreen" value="true" /><param name="allowscriptaccess" value="always" /><param name="movie" value="http://vimeo.com/moogaloop.swf?clip_id=4858057&server=vimeo.com&show_title=0&show_byline=0&show_portrait=0&color=01AAEA&fullscreen=1" /><embed src="http://vimeo.com/moogaloop.swf?clip_id=4858057&server=vimeo.com&show_title=0&show_byline=0&show_portrait=0&color=01AAEA&fullscreen=1" type="application/x-shockwave-flash" allowfullscreen="true" allowscriptaccess="always" width="400" height="240"></embed></object><p><a href="http://vimeo.com/4858057">Live particle system preview</a> from <a href="http://vimeo.com/shawncarroll">Shawn Carroll</a> on <a href="http://vimeo.com">Vimeo</a>.</p>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-10556738.post-22808135138253305032009-05-26T01:23:00.005-04:002009-05-26T01:27:37.641-04:00I love you Ogre/MogreAfter getting home from work, I decided to add a live preview to the resource browser. This essentially lets you see a real-time rendering of the object that is being displayed. For particle systems, it will actually show you the particle systems working in real-time directly in the resource browser. This should allow you to find just the right effect quickly.<br /><br />I'll be abstracting this into my generalized resource system that I had working in my old editor version so that I can plunk in particle systems to really show it off. Here's a sample video to watch. Pay attention to the knot right at the end. You can see the material rendering in real-time. Also, ignore the box that appears when I hover over objects, that's a work in progress :)<br /><br /><a href="http://www.vimeo.com/4840531">View in High-Definition (Recommended)</a><br><br /><a href="http://www.vimeo.com/download/video:3067993?v=2&e=1243319243&h=50c12621e4b35c3558971e126b1cbe0a&uh=9399fb6cbdc2f649199a019dd251465f">Download Original (6.02 MB)</a><br><br /><object width="400" height="245"><param name="allowfullscreen" value="true" /><param name="allowscriptaccess" value="always" /><param name="movie" value="http://vimeo.com/moogaloop.swf?clip_id=4840531&server=vimeo.com&show_title=0&show_byline=0&show_portrait=0&color=01AAEA&fullscreen=1" /><embed src="http://vimeo.com/moogaloop.swf?clip_id=4840531&server=vimeo.com&show_title=0&show_byline=0&show_portrait=0&color=01AAEA&fullscreen=1" type="application/x-shockwave-flash" allowfullscreen="true" allowscriptaccess="always" width="400" height="245"></embed></object><p><a href="http://vimeo.com/4840531">Live resource preview</a> from <a href="http://vimeo.com/shawncarroll">Shawn Carroll</a> on <a href="http://vimeo.com">Vimeo</a>.</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-48468064127346140602009-05-24T19:04:00.004-04:002009-05-24T19:10:12.139-04:00Resource BrowserI've started work on the resource browser which will hopefully make it a lot easier to find and place resources inside of the editor. Eventually, this will feature usability features such as tagging, searching, collections, and sorting but for now, it's pretty basic. There is a button in the editor to trigger the building of the thumbnails but eventually this will either be done by the asset server or by some sort of caching mechanism. For now, this works fine for me. Once you generate the thumbnails, you don't have to do it again, they just load with the editor.<br /><br />Currently, you can actually drag/drop each of the mesh resources into the viewport to have them appear which is a lot easier than creating an Entity scene object and then changing the mesh reference. This is a lot more visual and fits in with the "You need to be able to build a scene with the mouse" motto that I am going for with this editor.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_XYu0roVQoVA/ShnTf_IELFI/AAAAAAAAAK4/JYv2jNpqkXU/s1600-h/0008.bmp"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 245px;" src="http://3.bp.blogspot.com/_XYu0roVQoVA/ShnTf_IELFI/AAAAAAAAAK4/JYv2jNpqkXU/s400/0008.bmp" alt="" id="BLOGGER_PHOTO_ID_5339531379699100754" border="0" /></a>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-10556738.post-55082486123748024772009-04-29T23:14:00.005-04:002009-04-29T23:26:10.150-04:00Custom Object OverlaysI've been working on adding overlays to the editor lately. Here is the design of the actual overlay that I'll be using<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_XYu0roVQoVA/SfkXxnNU-vI/AAAAAAAAAKw/afdfp-BnyLI/s1600-h/overlay.bmp"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 260px;" src="http://2.bp.blogspot.com/_XYu0roVQoVA/SfkXxnNU-vI/AAAAAAAAAKw/afdfp-BnyLI/s400/overlay.bmp" alt="" id="BLOGGER_PHOTO_ID_5330317775075605234" border="0" /></a><br />This will appear over objects whenever you hover over them. Any type of information will easily be displayed inside of the overlay. This will allow any object to display detailed information about itself to hopefully make it easier to find objects inside of the scene. The overlay can be toggled on and off in case it's getting in the way. It'll follow the mouse cursor around and will be shifted slightly offset as to not get in the way.<br /><br />The system should be pretty automatic by allowing an OpenGL style Begin/AddTitle/AddBody/End style so the actual layout algorithm should be hidden from the user. I'll be integrating this into the actual editor over the next few days. I've also spent a bit of time scheduling out a task list for myself which should help out with getting stuff done on a regular basis. I've been really busy at home recently so I haven't done much coding in the past few weeks. That'll be changing.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-53793746370666477172009-04-20T21:04:00.002-04:002009-04-20T21:11:17.606-04:00MVC PatternsI've gone back and finally implemented a model-view-controller system in my editor. I have had plans on doing this for over a year and some now but I finally got around to doing it. Basically, all of my data and algorithms on said data are stored inside of the 'model' while the 'view' of that data in terms of what the editor wants have been broken apart. The collision data for instance is something that belongs in the view since it's an interpretation of the model and only the editor cares about that. The mesh name that an entity is using belongs in the model since it is an integral part of the data. The graphical data associated with that is handled by the view since different 3D engines might represent that 3D model differently.<br /><br />What this allows me to do is to work with my entire scene without having to load a 3D engine. This will work out great for tools since they can have the typed data that they want without having all of the graphical parts associated with it. We can attach different views as well for different applications.<br /><br />The other important thing this allows me to do is unit test my business logic separate from my UI interactions. For example, I can now test that my terrain modeling tools provide the proper deformations or material modifications since the graphics engine doesn't need to be loaded. As I've already built up a small testing suite in NUnit, this works out really well. I can make sure that the only parts to break in the future are the UI components. If a bug is reported that is related to the business algorithms, I can fix it, write a unit test for it, and it'll never make it into the build again.<br /><br />This has broken a few things that require refactoring but it'll be worth it in the end. Unit testing has proven invaluable for finding bugs in other parts that I believed my current changes couldn't possibly affect.<br /><br />I'm also working on the actual resource management system again for my editor which should be pretty kick ass. I had a primitive version of what I wanted done a long time ago but I want to spend some more time on it again. It should allow for a pretty nice work flow.<br /><br />Thanks to someone at work for reminding me that there is at least 1 person out there reading this. It's also nice to just have some place to ramble my thoughts off.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-28298749186131671382009-02-08T21:16:00.003-05:002009-02-08T21:25:15.322-05:00Switching BackI've been in the process of switching back to using .NET and C# to create the editor. The language itself is just much more suited to what I want to accomplish with the editor and I've always believed in using the right tools for the right job. I am now targeting the .NET platform using C# and Mogre which is a managed wrapper around Ogre.<br /><br />I am also focusing my attention on usability since it will be designers and artists using the editor and not programmers. As much as the property grid is an awesome tool, it is cumbersome, unintuitive, and sometimes hard to navigate for commonly used properties. I much prefer context sensitive menu bars and toolbars. In the following shots, the green tabs are added when a specific object is clicked. This allows for the most commonly used and changed properties to be readily accessible with just a few mouse clicks. Eventually, these will become customizable so that users can drop any properties they want and remove the pre-built ones all together.<br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_XYu0roVQoVA/SY-T0PJfn1I/AAAAAAAAAJw/wF8S9xtQO3w/s1600-h/0003.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 250px;" src="http://1.bp.blogspot.com/_XYu0roVQoVA/SY-T0PJfn1I/AAAAAAAAAJw/wF8S9xtQO3w/s400/0003.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5300617812067196754" /></a><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_XYu0roVQoVA/SY-T_bJJMhI/AAAAAAAAAJ4/1eY5N6LEToQ/s1600-h/0004.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 244px;" src="http://4.bp.blogspot.com/_XYu0roVQoVA/SY-T_bJJMhI/AAAAAAAAAJ4/1eY5N6LEToQ/s400/0004.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5300618004265513490" /></a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-27050191667906112602008-06-25T00:18:00.002-04:002008-06-25T00:25:21.110-04:00Per-Face SelectionSo after a single nights worth of work, I now have the ability to select individual faces from objects. I haven't implemented it in anything other than the 'BoxTrigger' but the way that it works now is fairly ideal. Each object itself can determine how it will report faces back during intersections. I just have it printing out which faces were hit but I will build a 'Face Shower Object' thingy tomorrow that will have wireframes around all of the faces. The great thing is, I have factored out a bit of the SelectionManager into the concept of a SelectionSet which holds all the information about the objects/faces/vertices that are currently selected which should be fairly reusable for selection groups if I ever decide to go down that route.<br /><br />I should have the implementation finished up in the next sitting or two which will hopefully be soon. I am going to be using this to finish up the 6th step from my list in the previous posting [June 21, 2008] towards my goal of a simple test room. I will allow you to select a face and then a material can be applied to it. Internally, this will most likely break the object up by adding another child sub mesh on the fly to it (I will combine them when they share the same material) and then you can use the material browser to select a material to apply. This will actually go a long way towards creating the room. The face removal should be fairly straight forward once I get face selection finished. I also plan to add support for vertex selection as well which should also be fairly straight forward since I will provide a 'helper' interface that has things like 'checkVertexForClick' which will take a matrix, a vertex, and a 'vertex size' which will check to see if a box that gets projected into screen space where the vertex is would be hit by a particular mouse coordinate. Then it should simply be a matter of looping over the vertices and feeding them in to this helper class.<br /><br />Once these two steps are done, the rest of it should be straight forward implementation things which just require me to have my butt in a chair for a while. All in all, things are going well. The editor is actually shaping up to be something useful. I might just get my work to review it [part of my contract with them] before I make an official release sometime. I will probably also end up taking suggestions and contributions from the community and integrating them into the editor when I get a chance. I still want control over this since I am using this for my own personal project but I will definitely integrate items when it makes sense to do so and release that back.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-41769504316669307522008-06-21T23:56:00.002-04:002008-06-22T00:10:34.052-04:00SuccessSo it turns out that I actually code a lot more effectively if I have a specific set of tasks to complete. I created a step by step guide to have the basic features required to build a simple test map. The test map is nothing spectacular. It's basically got a box that's been scaled out and had a face cut out of it for a 'connection' to another room. The other room is the same thing of another box with a face cutout that is going to be snapped to the first one. Each box starts with it's normals facing out but I am going to need to invert those so that the walls face in. I am also going to have to be able to assign a texture to each wall. So that's pretty much it. I have a lot of that functionality in there but none of it is really completed. There are a few bugs with each thing but now that I've tasked out everything, I am going through 1 by 1 and making sure everything works as expected before moving on. It's really nice to have a goal to work towards and having something tangible come of it.<br /><br />Here are the tasks that I've prepared in order to be able to do the test room. This is the order that I have been tackling them since yesterday so hopefully when I am finished, there won't be much else to do.<br /><br />1. Clear the scene<br />2. Translate tool<br />3. Scale tool<br />4. Box placement<br />5. Simple normal manipulation [just reverse them for now]<br />6. Texture assignment [per face or per object]<br />7. Face removal from a box<br />8. Vertex snapping<br />9. Object snapping<br />10. Light placement [point light]<br />11. Sprite icons for lights<br />12. Color adjustment for lights<br />13. Player start placement<br />14. 'Trigger' volumes<br />15. Rotate tool<br /><br />So I think that should more or less add the required functionality to be able to create the room I want. I think I am going to always sit down, plan out the creation of something, and break it down similarly in the future. It lets me know how long I'll be towards a target, keeps me focused on getting something useful accomplished, not just something cool, and it also gives me a specific feature to drive towards completing at any given time.<br /><br />That being said, I sat down today and did some actual work. I managed to fix/implement the first 4 features of that today. Granted, almost all of the framework was there but I at least fixed some bugs and made the scale and translate tool function as they are supposed to.<br /><br />As it stands now, I've given myself the weekends and 2 'work days' throughout the week to be spending on this. I also gave rough estimates for how long things will take. Based on that [which may be horribly inaccurate], it appears that I should have all of this done by mid August some time. As far as that is, I think I can pull it back into late July which will be nice.<br /><br />As far as the editor is concerned, I won't be recreating Maya/Max at all but I will be allowing for simple face manipulation that will allow you to create a basic room, block off some sections with walls, and place ramps and things so you can have multiple levels. Anything more complicated than that and I'll have to allow you to import it as a mesh from your favorite modeling package. I will have to create a suite of tools to allow you to place objects easily and line things up nicely so that will probably be coming soon as one of the next few use cases.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-72751003533373123912008-06-21T02:07:00.002-04:002008-06-21T02:15:04.652-04:00SchedulingIn my attempt to take a much more professional approach to the creation of my editor, I am actually using some scheduling software. It is called Hansoft and I am using the free license that they give to attempt to manage myself. I find that I am always wandering off the path towards actually getting something usable so in an effort to control that, I will become my own manager.<br /><br />I just installed it and have been playing around with it for about an hour or so. It seems to support everything I will need: bugs, tasks, and scheduling. Hopefully I will be better at estimating how long features will take so I can be more committed to my release dates when I set them. Currently, I have too much of a 'when it is done' attitude and would like to correct that.<br /><br />As an addition to this, I am also trying to come up with 'use cases' for the editor. I want to be able to build a test room as my first real milestone for the editor. In order to accomplish that, I am going to strip away all of the unfinished features, tuck them somewhere in a directory on my computer for later, and start fresh and actually finish a feature and flesh it out before I move on. That being said, the goals I have laid out for myself will mean that I can make a basic test map of 2 rooms [just simple cubes] that are snapped together with 2 lights inside as well as having 2 'volumes' inside that will be read in as triggers for the game engine whenever that gets completed. I have given a really rough schedule for this [I will go back and re-evaluate my estimates soon when I'm more rested] and it appears that I should be able to finish all of this by the end of August if I just work on the weekends and 2 days through out the work week. That being said, I am going away for vacation for 1 weekend in July so that will have to be taken into account. At least now I have a more realistic estimate as to how long it will take me which is always a good thing. It's humbling to know that what I want will take me 6 years but what I need will only take me 1 [as a metaphor, not in reality].<br /><br />I'll probably post a schedule from time to time to show what I am working on, what's currently finished, and so that people can have more of an insight into my own work habits. I will post some more technical details about the tools I am using in an upcoming post.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-12239853649598157332008-05-10T13:36:00.002-04:002008-05-10T13:45:21.082-04:00RefactoringI have been looking at my code lately and it's time for another refactor. I've noticed that almost all of my SceneObject types require transformations. There are only a select few that do not yet I have implemented the transformation system through the generic property/command system. This worked well at the start but as I implement more complex, non-primitive, types for the editor, I'm realizing that it can be a pain to re-implement the same functionality over and over again.<br /><br />I am currently working on a BoxTrigger which is composed of a SceneNode and a wireframe box (technically it doesn't require the SceneNode but I need it for later). I want to be able to translate, rotate, and scale this object but in order to do that, I have to forward the methods on to the SceneNode. I'd have to write all sorts of code to handle the transformations again when I really shouldn't have to.<br /><br />My proposed solution, after looking at Sinbads wxOgreMVC code, is to implement the transforms on the base SceneObject class and then declare a way for each derived type to receive a notification when the transform changes. This will simply allow me to add the 'position', 'scale', and 'orientation' properties to my class and everything else should work.<br /><br />The tools will need a very small rewrite to handle this but that shouldn't take more than 10 minutes. In order to transform a SceneObject, the tool should first check to see if the any of the 3 properties above are present. If they are, then the associated methods should be relevant. For instance, the translate tool should see if the 'position' property is available. If it is, it can then call 'translate', 'setPosition', 'getWorldPosition', etc knowing that they are fully implemented.<br /><br />When it comes time to save objects, the transform information may require special handling. I believe that the 'position' property should be all that is required to be written out.<br /><br />I'm doing some testing at the BoxTrigger level before I implement this at the base level but so far, everything has worked accordingly. I believe this transition should make all future objects a lot easier to implement and work with. Considering that most of the editor objects are concerned with transformation information, having it available at the base level should be a major feature.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-44699325299751980162008-04-24T15:07:00.002-04:002008-04-24T15:20:39.465-04:00A little too quietSo it's been a few months since I last posted. I got busy with school and living in a house with 4 other people. Let's just say that there was a lot of Halo that happened. Unfortunately, that experience has come to a close. I wrote my last exam today and will be moving out on Sunday. I'll be in my new place with my fiance on Monday/Tuesday which will be our own place where we will stay for a few years. Eventually we're looking at getting a house. I also start my job again (game programmer) in a week and a half.<br /><br />What this all means is that once the move is done, I will finally be able to work consistently on my projects again. The editor will start getting some much needed love and I am hoping to add a few things into the RTS game.<br /><br />The main thing that I've been toying around with lately has been a visual scripting system. There are examples of this all over the place lately. The two that I first saw were the editor for the Crytek engine as well as the editor for the Unreal engine. Crytek calls their version FlowGraph with an example below.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://img89.imageshack.us/img89/7563/54705348xq8.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px;" src="http://img89.imageshack.us/img89/7563/54705348xq8.jpg" border="0" alt="" /></a><br /><br />I have tried both of the systems in a limited capacity and I just find that the Crytek version is easier to work with and a much nicer interface than Unreal's version. That being said, I haven't actually compared the capabilities of each but I haven't run into anything that I'd want to do that I couldn't in FlowGraph.<br /><br />I've been experimenting with my own system and I seem to have come up with a reasonable solution. It's heavily based on the Crysis SDK but since I don't have actual source code for it all, I've had to do parts from scratch. I'm hoping that I will be able to implement this system into the RTS so that scripted sequences as well as some basic AI logic could be laid out with this tool.<br /><br />There are a lot of possibilities that I have in my head for how this system could be used which I will explain in a future post. Needless to say, I will try to make this as powerful as possible so that I don't have to resort to the code-compile-wait-test-debug-wait-redo cycle that a lot of development gets stuck in. If I can chop out the compile part, that should save me a lot of time and at the same time will open up creation to many more people than just coders.<br /><br />I'm also looking into toLua to expose a lot of the game to Lua so that I can write modules and some AI in lua without having to constantly recompile. At some point, I'd like to be able to define nodes in my visual logic system in Lua so that new functionality could be added on the fly without recompiling all the time.<br /><br />There are a few other things on the burner right now but I am going to try and finish fixing the transform tools now that I've merged the 'tool' and 'gizmo' system into one system. This will make it a lot more consistent when a new piece of functionality is required.<br /><br />And now. If you'll excuse me, I am going to get myself back into some coding.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-23016644001348893082008-02-01T15:41:00.000-05:002008-02-01T15:46:50.188-05:00DeformationsWell I am now officially employed back in the game development world once again. I am back working for the same company that hired me for a co-op position last year. I'll be starting in May. So I'm excited about that. I'll still be continuing work on the editor as well as on my game so that shouldn't change.<br /><br />As for the editor itself, I now have the concept of a 'mode' which will be a distinct state for the editor to be working in. This will help the plugins organize everything that they need in order for their particular 'mode' to work. For instance, the terrain editing mode will disable regular object selection so that you can only manipulate the terrain.<br /><br />Each mode can have a custom tool window that is queried for, and managed by, the editor whenever that mode gets activated. You can see the terrain tool coming along in the video below, with the higher quality version <a href="http://www.vimeo.com/655507">available</a>. It's tool window is shown in the lower left hand side of the screen which I use to change how I am manipulating the terrain.<br /><br /><a href="http://www.vimeo.com/655507">View in High-Definition (Recommended)</a><br><br /><a href="http://www.vimeo.com/download/video:30244493">Download Original (6.49 MB)</a><br><br /><object type="application/x-shockwave-flash" width="400" height="244" data="http://www.vimeo.com/moogaloop.swf?clip_id=655507&server=www.vimeo.com&fullscreen=1&show_title=0&show_byline=0&show_portrait=0&color=01AAEA"> <param name="quality" value="best" /> <param name="allowfullscreen" value="true" /> <param name="scale" value="showAll" /> <param name="movie" value="http://www.vimeo.com/moogaloop.swf?clip_id=655507&server=www.vimeo.com&fullscreen=1&show_title=0&show_byline=0&show_portrait=0&color=01AAEA" /></object><br /><a href="http://www.vimeo.com/655507/l:embed_655507">Intermediate Terrain Editing</a> from <a href="http://www.vimeo.com/user344756/l:embed_655507">Shawn Carroll</a> on <a href="http://vimeo.com/l:embed_655507">Vimeo</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-41843648760780024652008-01-16T01:59:00.000-05:002008-01-16T02:13:22.284-05:00Terrain EditingTwo new things:<br /><br />1) I've started working on terrain editing inside of the editor. I think this will be one of the most used features other than direct object placement so I'd like to make sure it's possible to do. I have to come up with a 'mode' system that will allow the editor to reside in certain modes. That is, object placement will be one mode while terrain editing will be another. No two nodes can be active at the same time so that they can be sure that their settings won't be changed while they are on. The switching between modes can appear automatic or manual to the user. If you click on an object to place it, you'll automatically be kicked into the 'object placement' mode. On the other hand, you will have to manually hit an 'edit' button to go into terrain editing mode. It's up to the designer how each of these modes will be activated.<br /><br />2) I am going to try and upload videos now showing off the editor in action. I find that videos show more than a single static screen shot can. I'll post the videos through Vimeo since it appears to offer the best quality. I'll post the embedded video directly on this blog with a link to the 'higher quality' one on the Vimeo site. The originally will also be available for download on the Vimeo site (bottom right) for each of my videos if you want to save them to your local computer.<br /><br />And without much further wait, here is my first video showing off the ability to raise terrain in the editor. I used the amazing editable terrain manager which was not written by me for this. I wanted a proof of concept to make sure it would be doable. I have to add proper support but it's running inside of the editor and was able to be interfaced as a plugin which was all I wanted to confirm.<br /><br /><a href="http://www.vimeo.com/612202">View in High-Definition (Recommended)</a><br><br /><a href="http://www.vimeo.com/download/video:26253417">Download Original (9.79 MB)</a><br><br /><object type="application/x-shockwave-flash" width="400" height="243" data="http://www.vimeo.com/moogaloop.swf?clip_id=612202&server=www.vimeo.com&fullscreen=1&show_title=0&show_byline=0&show_portrait=0&color=01AAEA"> <param name="quality" value="best" /> <param name="allowfullscreen" value="true" /> <param name="scale" value="showAll" /> <param name="movie" value="http://www.vimeo.com/moogaloop.swf?clip_id=612202&server=www.vimeo.com&fullscreen=1&show_title=0&show_byline=0&show_portrait=0&color=01AAEA" /></object>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-45115783008178912942007-12-27T17:41:00.000-05:002007-12-27T18:00:11.003-05:00Resource BrowsersI've implemented a system where a SceneObject can add a 'resource' property to the list of editable properties. What this will do is provide a text field as well as a '...' button next to it inside of the PropertyGrid. When the user clicks on the ..., a browser window is opened (all handled through the editor) for the appropriate type of resource. This browser window can then be used to preview and select a new resource that should be linked in. Of course, these browser windows can only handle specific types such as a material or a sound, so they will be able to be plugged in to the editor. When a resource is going to be changed, an appropriate browser is looked up and presented to the user.<br /><br />So far, I have implemented a browser for Materials which will most likely also work with other types of resources that are built in to Ogre but I have to provide a ResourceFactory for those. It simply defines a type and the ability to query for the name and a preview SceneObject of it.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp3.blogger.com/_XYu0roVQoVA/R3QuD8VufNI/AAAAAAAAAGQ/6XXEbfJVL6I/s1600-h/screenshot_017.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp3.blogger.com/_XYu0roVQoVA/R3QuD8VufNI/AAAAAAAAAGQ/6XXEbfJVL6I/s400/screenshot_017.PNG" alt="" id="BLOGGER_PHOTO_ID_5148790919263059154" border="0" /></a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-11767209768434944982007-12-19T04:07:00.000-05:002007-12-19T05:03:59.238-05:00Example Code[This is just a temporary theme. I think it's fairly dark so I will either change that or find something to lighten it up.]<br /><br />I just wanted to post some code to show how working with my properties can work. I've switched them over to use the Any class that is built in to Ogre but originally I was using my own version of it. There is more to a property itself than just the Any instance but a property does have one of them attached called the 'propertyValue'.<br /><br />Here is the code I use to actually export the properties of *any* SceneObject at all. This works on Entities, ParticleSystems, Lights, and will work on any future thing out there. *All* of the code in the editor is like this. There is no notion of a particular type *anywhere* except inside the actual SceneObject derived classes themselves. So something that works on one SceneObject will work on a completely different type of SceneObject as long as it provides the same properties and commands (commands are 'issued' to the SceneObject through a generic interface). I'll post an example of the translate tool a bit later. But needless to say, I write code once and if it works, it'll work for anything. I know that whenever I implement sounds, the translate tool will work on those without having to touch the code. It's nice being able to expect that.<br /><br /><pre><br />void XmlSceneExporter::_exportProperties ( SceneObject* rootObject, wxXmlNode* propertiesNode )<br />{<br /> SceneObjectPropertyList properties;<br /> rootObject->getProperties( &properties );<br /><br /> if( properties.size() == 0 )<br /> return;<br /><br /> wxXmlNode* propertiesNode = new wxXmlNode( node, wxXML_ELEMENT_NODE, "properties" );<br /><br /> size_t numChildren = properties.size();<br /> for( size_t i = 0; i < numChildren; i++ )<br /> {<br /> Any propertyValue = properties[i].getPropertyValue();<br /> if ( propertyValue.isEmpty() )<br /> continue;<br /><br /> String strData;<br /> if( StringConverter::convertToString( propertyvalue, &strData ) == false )<br /> continue;<br /><br /> wxXmlNode* propNode = new wxXmlNode( propertiesNode, wxXML_ELEMENT_NODE, "property" );<br /> propNode->AddProperty( "name", properties[i].getName() );<br /> propNode->AddProperty( "value", strValue );<br /> }<br />}<br /></pre><br /><br /><br />And here's the example 'convertToString' that is used. It's all very simplistic. And this will allow future objects to be registered and saved without touching anything else. Just implement a new TypeDescriptor, register it (at run-time) with the TypeDescriptorManager, and you're all set.<br /><br /><br /><pre><br />bool StringConverter::convertToString( const Any& property, String* strData )<br />{<br /> String strValue;<br /> const TypeDescriptor* descriptor;<br /> TypeDescriptorManager* mgr = TypeDescriptorManager::getSingletonPtr();<br /><br /> descriptor = mgr->findTypeDescriptor( propertyValue.getType() );<br /> if( descriptor != NULL && descriptor->canConvertToString() )<br /> return descriptor->convertToString( propertyValue, &strValue );<br /><br /> return false;<br />}<br /></pre><br /><br /><br /><br />I am rather enjoying generic programming like this :) I haven't found myself going back to rework old code to fit a new object that I didn't expect to use. Anyways. I have another exam in 8 hours so I guess I'll start studying for it now.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-10556738.post-82641134518760422062007-12-18T08:23:00.000-05:002007-12-18T08:27:49.868-05:00Saving the world, one scene at a timeThe conversion of the XmlSceneExporter is now complete. I can now save/load anything that's creatable inside the editor so far. It actually only took me about 2 hours to port it over, write any missing functionality, and test it. I had to change some internal workings in my SceneObject class as well as introduce a new class called a TypeDescriptor since I no longer had the power of .NET's Reflection. The TypeDescriptors are pluggable and they basically provide features for a particular type. For instance, they will provide a convert[To/From]String method so that data can be written to disk and reloaded again. I will be providing basic ones for all of the various things I'll need to save inside of Ogre but they can be plugged in through a plugin which means that people can add new types that are serializable with any existing exporter that uses TypeDescriptors (which will most likely be all of them).<br /><br />I also revamped the blog style a bit. I will be searching for a better template eventually but for now, I just wanted something different. Anyways. I have a final exam to write in half an hour so I should possibly do something towards that :)Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-10556738.post-557414492351943622007-12-16T20:29:00.000-05:002007-12-16T21:19:16.851-05:00"I like to move it, move it"The translate tool is done. I had changed how the selection manager was processing events which required some changes to the tools. I also was getting some strange issues with control focus and wxWidgets which ended up getting solved. I had to force the render panel to get focus when it was clicked.<br /><br />One of the major down falls to switching over was that I wasn't NULL'ing out my pointers in Managed C++ since this was done for me. Now that I'm using C++, this has come back to haunt my debugging dreams. I've made a large pass over the code base and have initialized all my variables in the constructor but there are still some NULLs getting passed around that somehow worked in Managed C++. Who knows. It's all getting solved and it's making the code more stable with every step.<br /><br />I am going to see about implementing the next plugin which is the Sample Exporter. At least this will let me load up the larger scenes that I had saved before. I'm tired of looking at a single test OgreHead. I am really not sure how I'm going to write out all of the variables right now. With .NET, I could write a converter that would parse from/to a string which meant that I could use this for my PropertyGrid display as well as for writing out to a file. Since C++ doesn't natively support this, I believe I am going to write a 'converter' class which will take a specific type and be able to parse to/from a string. For most types, I can convert *to* a string using Ogre's built in StringConverter class. I'll have to convert back from a string but worse things have happened. I believe once I have this, I'll be able to say Convert::toString( const Any& someObject ) and based on the value returned from Any::getType, I'll be able to match it to a specific converter and it'll be written out. The joy of this is that the exporter won't need to know how to save any particular value. The down side is that in the future, if the converter changes, there isn't really any way to know about it from an exporter point of view. That is, data could be written out with v1.0 of TypeX Converter but then that could be replaced with v2.0 of TypeX Converter which no longer recognizes that particular format. I'm sure I'll think of something other than just crashing :)<br /><br />It's nice being able to finally put a scene together. Here is my current progress:<br /><br />Base Editor: 95%<br /><br />Plugins<br />--------<br />Basic Align Tools: 0%<br />Basic Object Editors: 0%<br />Properties Window: 0%<br />Sample Exporter: 0%<br />Basic Gizmos: 50% - Translate is done, the others are extremely similar to it<br />Basic Object Factories: 100%<br />Scene Graph Window: 100%<br />Resource Browser: 100%<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp3.blogger.com/_XYu0roVQoVA/R2XcmsVue8I/AAAAAAAAACY/-IiKs5EfojE/s1600-h/screenshot_016.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp3.blogger.com/_XYu0roVQoVA/R2XcmsVue8I/AAAAAAAAACY/-IiKs5EfojE/s400/screenshot_016.PNG" alt="" id="BLOGGER_PHOTO_ID_5144760706636086210" border="0" /></a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-69680281597499801152007-12-15T20:03:00.000-05:002007-12-15T20:07:48.125-05:00Port JobThe porting is coming along nicely. I've made a few internal changes but nothing huge. The biggest problem I've had is that I had tons of memory leaks. I have removed all of them so far. The editor starts up and exits cleanly from start to finish. I still have to figure out how to handle exceptions better since once one happens, the app usually crashes and burns. This is going to be an issue between exceptions and wxWidgets but I'll get there.<br /><br />I've completed the following plugins:<br /><br />Scene Graph Tree<br />Resource Browser<br />Basic Object Factories<br /><br />and am working on the Gizmos plugin which contains the translate/rotate/scale tools that will be provided. I will have to overhaul the UI once the porting is done to make it nicer to look at. Right now, I'm concerned with getting it functional to where it was with .NET/CLI C++<br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_XYu0roVQoVA/R2R6SMVue7I/AAAAAAAAACQ/yOm-flqaowI/s1600-h/screenshot_015.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp0.blogger.com/_XYu0roVQoVA/R2R6SMVue7I/AAAAAAAAACQ/yOm-flqaowI/s400/screenshot_015.PNG" alt="" id="BLOGGER_PHOTO_ID_5144371127332535218" border="0" /></a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-31150847133012913452007-12-14T13:58:00.000-05:002007-12-14T17:49:49.902-05:00Break UpI'm sorry to be reporting this but the team of Doug and myself has broken up. We're still talking and will hopefully continue to collaborate on things but as a dedicated team, it fell apart. I am the one to take all the blame here. I simply didn't keep up on things and let emails slip and responses be delayed longer than I should have. Things just ended up drifting apart to the point where I think it was obvious to both of us that it wasn't really working anymore. We're still chatting over email though so hopefully we'll still be able to exchange ideas. There isn't really much more to say on the issue. I feel bad about it so hopefully I can use it as a learning experience about the dedication I need in order to bring other people onto a project.<br /><br />In other news, the editor is still being worked on. I'm going to keep going with the project itself so nothing has changed in that respect. A lot of the focus has shifted away from the game as I haven't worked on that in ages. I am trying to develop an awesome editor which I can give back to the community and hopefully see a lot of useful stuff come out of it. I'll be using that to design as much of the game as I can. I want almost everything to be defined in the editor so that I can avoid changing code when I don't need to. It'll also allow for rapid development of new units and levels once that stage has arrived.<br /><br />I am however in a major overhaul of the editor. I am switching away from .NET with Managed C++ and moving into using wxWidgets and C++. I hit a few barriers in .NET that aren't documented at all and nobody really knows how to do them. I also found myself writing a lot of wrapper code around Ogre objects to pass things around inside of the managed environment. With the move to C++, I can use a lot of the features of Ogre as well as the awesome 'Any' class which can wrap anything up to be passed around. I also go back to straight C++ which is what I'm most comfortable with as well as what Ogre is written in. This will have the advantage that when people write plugins or modify the editor, it will be in the language that is used with Ogre.<br /><br />I am making good progress so far. I've been leaving a bit of code commented out here and there, marked with a 'todo' for later, since features aren't finished but the base editor package is about 95% done. In terms of progress, here is my list:<br /><br />Base Editor: 95%<br /><br />Plugins<br />--------<br />Basic Align Tools: 0%<br />Basic Gizmos: 0%<br />Basic Object Editors: 0%<br />Basic Object Factories: 100%<br />Properties Window: 0%<br />Resource Browser: 100%<br />Sample Exporter: 0%<br />Scene Graph Window: 0%Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-58169229827329653852007-10-07T19:56:00.001-04:002007-10-07T20:08:18.767-04:00ProgressAfter getting sucked up by school again, I've finally started dedicating myself to writing personal code. I'm still reworking behind the scenes to find a very awesome framework. I'm almost at the point where I have an Entity editor where you can bring in arbitrary SceneObjects (not just necessarily Ogre specific classes) and attach them to the Entity. The Entity itself has no idea what is being attached to it and the other object has no idea it is being attached to an Entity. It simply knows that each object supports the appropriate commands to just have it work.<br /><br />In the process, I've realized that I'm going to need a generic "instance provider" for each type. That is, I need a way, given a particular type, to ask somehow about the names of all of the objects that exist of that type. I also need a way to say "create a sample preview in this scene of that particular type" without knowing what it is exactly I'm constructing. What this means is that, for example, the Entity is constructed very differently than a particle system. I don't want the editor to know about these types so I would like a way for the entity editor to query for the names of entities and the names of particle systems. Then I need some "preview provider" to be able to say, "create an 'entity' with the name 'xx' attached to this parent." and "create a 'particle system' with the name 'xx' attached to this parent". I don't want those to be two different operations. If I get this, it would mean that any object in the future that provides these things will automatically get picked up by the entity editor as potential things to be attached to bones as well as being able to provide an automatic preview of the object itself. That's the ideal goal.<br /><br />I've already got a decent amount of this working. I already have the list of 'types' that will provide me with the commands and properties I need to accomplish my goals at run-time so now I just need to be able to produce a list of instance names as well as provide an automatic preview for any given type and I'm all set. That's what I'm working on now.<br /><br />In the following shot, you can see that I've added a wireframe overlay on to the selected objects. This is an automatic thing that happens now on any selected entity which is rather nice. I didn't create this effect, credit goes to someone in the forums (I can't remember where I saw it). It's done at run-time as follows:<br /><ol><li>Create an additional pass on each material for the Entity</li><li>Disable lighting on the new pass</li><li>Set the polygon mode as PM_WIREFRAME</li><li>Set a depth bias so that the wireframe doesn't z-fight with the actual object. (I'm using 10.0)</li></ol>Works rather nicely.<br /><br />You can also see that I have a sword in the lizard mans hands in the entity editor. That was actually created, placed, rotated, and positioned correctly using nothing but the editor. Each viewport can have their own gizmos which is nice. This came for free from the 'scene' concept. Each scene has its own set of gizmos. There is always the default world scene but anything is able to create additional scenes. The ResourceBrowser creates an additional scene for its preview window and the EntityEditor creates its own.<br /><br />Each scene has the following unique instances:<br /><ul><li>Ogre::SceneManager</li><li>Selection Manager</li><li>Gizmo Manager</li><li>Sceneobject Manager</li></ul>Anyways. I'm back to implementing this 'generic browser'. It'll eventually be used for everything that creates an object so you can hit 'New Object' and each editor piece will be able to control what shows up in window.<br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp2.blogger.com/_XYu0roVQoVA/RwlzSQm6v3I/AAAAAAAAABc/5ZTdEw4LFKA/s1600-h/screenshot_014.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp2.blogger.com/_XYu0roVQoVA/RwlzSQm6v3I/AAAAAAAAABc/5ZTdEw4LFKA/s400/screenshot_014.PNG" alt="" id="BLOGGER_PHOTO_ID_5118749209016319858" border="0" /></a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-84490306748004794142007-09-15T19:21:00.000-04:002007-09-15T19:35:55.962-04:00Ortho ViewportsSo I've implemented the 3 standard ortho viewports that are found in almost all editors. It only took me about an hour in total to get it done including compile times. All the viewport code worked, I just needed to add specific camera controls to handle each specific viewport. Everything else just worked automagically. I am having one problem with the translate tool if you start it in one window and then continue its motion in another window but that'll get solved.<br /><br />The controls still need to be refined but they work. It's just a matter of tweaking at this point. I'm also going to try and list out a defined set of tasks that I've completed for each update so I can see the internal progress myself.<br /><br />Change Log:<br /><ul><li> A front/side/top orthographic viewport is shown on the main page</li><li> The actual Entity that was clicked is selected now instead of the parent object.</li><li> The Translate/Rotate gizmos check the object and its parent object for the required properties</li><li>The Translate/Rotate gizmos now cache the selected scene objects that support the requirements so that they can simply be looped over instead of checking the requirements each frame.</li><li>Deleting an Entity no longer takes its parent object (usually a SceneNode) and the children of that parent with it.</li><li>The ResourceBrowser no longer shows a bounding box after the first object is changed.</li><li>Viewports now support camera styles to define their movement types: Free, Front, Side, Top<br /></li></ul><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_XYu0roVQoVA/RuxqZKDaE6I/AAAAAAAAABU/jLRCSLb1C38/s1600-h/screenshot_013.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp0.blogger.com/_XYu0roVQoVA/RuxqZKDaE6I/AAAAAAAAABU/jLRCSLb1C38/s400/screenshot_013.PNG" alt="" id="BLOGGER_PHOTO_ID_5110576657586590626" border="0" /></a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-31392845011430746372007-09-12T22:34:00.000-04:002007-09-12T22:51:19.081-04:00UpdateSo not much has visually changed in the editor but again, lots of behind the scenes refactoring has taken place. I've created an internal OgreScene which is responsible for creating and updating all of the various managers that go along with it. Any plugin can create their own scene and they'll get gizmos and SceneObjects and a selection manager all for free right now. It's worked out well for the ResourceBrowser and the Entity Editor in that they can create their own OgreScene and they will end up with a movable camera as well as selection and gizmos. Eventually, each OgreScene will be able to turn certain features on and off at will to customize the particular scene.<br /><br />I've enhanced the entity editor a bit which ended up creating a lot more wrapping around the Ogre objects. The properties/commands setup has worked out very well. I've had to add an additional feature which I'm calling "associated objects". These would be things like bones which make up an entity and attached objects. I've managed to convert all the Ogre specific code over to use the SceneObject system in the ResourceBrowser and in the EntityEditor.<br /><br />I've also recently moved twice in the past month which has created a lot of running around for me. But I think I'm fairly settled now which is nice for a change. I'm hoping that I'll be able to actually get some real coding done now which will be nice. I'm really trucking along with the editor to try and get as much functionality in there as I can so that eventually, the entire game will be all data driven which means I can recruit a bunch of people to help put together some art and media and then some designers to actually piece it all together.<br /><br />Doug is hard at work on some map media which I'm really looking forward to seeing. He's put together an awesome looking tree so far which I'll post next time once I ask if he minds posting the pic he sent me. It's a WIP so he wasn't pleased with it but I think that it looks really awesome. So we'll see whether he can finish it or if I can post the WIP version.<br /><br />I did add the ability to preview ParticleSystems inside the ResourceBrowser. This again fell out of the SceneObject system as it was a few lines of code. The main thing here though is that the actual thing could be anything from a particle system to an entire prefabbed human base with 14 different buildings in it and people moving around inside. It doesn't matter to the ResourceBrowser.<br /><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp2.blogger.com/_XYu0roVQoVA/RuiljqDaE5I/AAAAAAAAABM/lrEo_6AKCf8/s1600-h/screenshot_012.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp2.blogger.com/_XYu0roVQoVA/RuiljqDaE5I/AAAAAAAAABM/lrEo_6AKCf8/s400/screenshot_012.png" alt="" id="BLOGGER_PHOTO_ID_5109515809254413202" border="0" /></a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-10556738.post-82301564413677193962007-07-16T19:28:00.001-04:002007-07-16T19:33:17.204-04:00AlignmentI've taken a stab at creating an "align" tool inside of the editor. Again, to make sure I am exposing everything I need to for outside developers, I wrote this as a plugin. I need better support for adding toolbars and stuff but it'll get there.<br /><br />This will align any object that exposes the appropriate properties. I should probably throw up a warning or something when an object is selected that can't be aligned using the current settings. But for the most part, you can grab a scene node and either align it based on location or on bounding box. Bounding box is the most useful since the location can be arbitrary depending on what is attached to it. Bounding box allows you to align two objects to be along the same axis on the Z or to even be right next to each other except along the x-axis. It's all up to you.<br /><br />I've stolen the icons from Maya so they'll have to be replaced sometime. But all the features work. It'll make things a lot easier to lay down in an organized fashion. I think I will need to implement grid-snapping soon as well with customized values so you can create bigger/smaller grids. This will be a must-have feature when we get to lay down the terrain tiles.<br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp2.blogger.com/_XYu0roVQoVA/Rpv_rcwMEjI/AAAAAAAAABE/nSqpKEAYJKU/s1600-h/screenshot_010.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp2.blogger.com/_XYu0roVQoVA/Rpv_rcwMEjI/AAAAAAAAABE/nSqpKEAYJKU/s400/screenshot_010.PNG" alt="" id="BLOGGER_PHOTO_ID_5087941325962875442" border="0" /></a>Unknownnoreply@blogger.com0