The Crowbar Editor Testing Thread [a0.03]
The deadline for my final year project report is fast approaching (21st April), so now has come the time to see if I can get some real-life geeks to test out the Crowbar editor so that I can evaluate how successful it's been so far.
What stage are we at?
I took the editor on as an FYP at university basically because I'm terrible with projects and usually burn out before I finish them, so I wanted to have to work to a deadline and be required to have something to show for it at the end.
The current build is very much a prototype: for the past 7 months I've been muddling through and learning things as I go along, so I wouldn't say it represents what the final product should look like, especially since I'm stuck with an outdated 3D framework until the end of this term. It does, however, give an idea of how the core functionality should be expected to work, being based around a hierarchical object structure.
What the hell is a "hierarchical object structure"?
In Hammer, you can only create brushes in "world space": translation, rotation and scaling are all done in world units. In Crowbar, you create brushes in world space by default, but you (will ASAP) also have the option to "parent" them to another object. This is very much like how parenting works in Source itself: when the parent moves, its children move with it; when the parent rotates, its children rotate relative to it. What this means for the editor is that if you parent brush A to brush B and then rotate brush B, you will still be able to translate, rotate or scale brush A in its own local orientation, instead of being restricted to only doing these operations along the world axes. (In Hammer, there's no way to make a brush "longer" on one axis, once it's been rotated to a weird angle, without rotating it back to a convenient orientation first.)
What's in this test release?
As of right now (alpha 0.02), the functionality is pretty basic. If I can implement a few more things over this weekend then I'll update it, but I've been gunning for a bare-bones implementation that demonstrates the basic operations that we're used to in Hammer. The implementation for object hierarchies is there, but you can't manipulate them through the actual UI yet.
The salient points are thus:
Controls are:
Urgent things I would like to address ASAP:
Where can I download it?
If people want I can also make an OSX version available but I don't have any experience running those applications outside of the IDE environment yet, so it may require a bit of research and testing for me to get it working.
What sort of feedback would be useful?
Any feedback, positive or negative, is much appreciated. I've been coding this for so long that I've lost any semblance of objectivity, so I really do need opinions of genuine users in order to know what works and what doesn't.
Specifically, the following are helpful:
Finally, just throw stuff at the application and see what crashes it. Let's stress-test this.
The deadline for my final year project report is fast approaching (21st April), so now has come the time to see if I can get some real-life geeks to test out the Crowbar editor so that I can evaluate how successful it's been so far.
What stage are we at?
I took the editor on as an FYP at university basically because I'm terrible with projects and usually burn out before I finish them, so I wanted to have to work to a deadline and be required to have something to show for it at the end.
The current build is very much a prototype: for the past 7 months I've been muddling through and learning things as I go along, so I wouldn't say it represents what the final product should look like, especially since I'm stuck with an outdated 3D framework until the end of this term. It does, however, give an idea of how the core functionality should be expected to work, being based around a hierarchical object structure.
What the hell is a "hierarchical object structure"?
In Hammer, you can only create brushes in "world space": translation, rotation and scaling are all done in world units. In Crowbar, you create brushes in world space by default, but you (will ASAP) also have the option to "parent" them to another object. This is very much like how parenting works in Source itself: when the parent moves, its children move with it; when the parent rotates, its children rotate relative to it. What this means for the editor is that if you parent brush A to brush B and then rotate brush B, you will still be able to translate, rotate or scale brush A in its own local orientation, instead of being restricted to only doing these operations along the world axes. (In Hammer, there's no way to make a brush "longer" on one axis, once it's been rotated to a weird angle, without rotating it back to a convenient orientation first.)
What's in this test release?
As of right now (alpha 0.02), the functionality is pretty basic. If I can implement a few more things over this weekend then I'll update it, but I've been gunning for a bare-bones implementation that demonstrates the basic operations that we're used to in Hammer. The implementation for object hierarchies is there, but you can't manipulate them through the actual UI yet.
The salient points are thus:
- There are only two viewports. This appears to be a limitation of the current 3D framework I'm using - if I tried to add more 2D viewports, all the brushes in the subsequent views would start doing freaky things like rendering as separate copies of the grid and crashing the program if you zoomed in too close. As I mentioned above, the 3D framework I'm stuck with (I started using it on September before the newer version had come out and it's too late to change now) I will be updating once I've finished the project assignment and am back to working on my own schedule, so it's just for this prototype. The 2D view does allow you to change the orientation between side, front and top.
- Select, Create Brush and Face Edit tools are available. Translation and scaling of brushes are available but not rotation yet. No other tools as of right now.
- A sample set of textures is packaged with the editor. It currently reads PNGs from the textures directory where the executable is located. If you want to test out more textures from TF2 or any other game, convert them to PNGs and put them in the correct subfolder. Rendering of transparent/translucent materials may be a bit wacky because I haven't tested it yet, but by all means give it a go.
- Maps can be exported to VMF with "Save As", but not read yet. The exported VMFs should be loadable in Hammer (ie. tell me if they're not).
- There is no undo/redo yet.
Controls are:
- Z toggles mouselook mode in the 3D view.
- W/A/S/D control the 3D camera. Q and E move it up and down.
- Space will allow you to pan the grid in the 2D view.
- Mouse wheel zooms the 2D grid in and out.
Tab toggles visibility of the 2D view.
Left click selects, right click applies the current texture when using the face edit tool. - When translating brushes, Alt disables grid snapping and Ctrl enables half-grid snapping. Snapping is applied to the brush origin (the square in the centre of the brush in the 2D view).
Urgent things I would like to address ASAP:
- Shift-dragging should clone the selected brushes.
- Translating a group of brushes will cause them to "ripple" when snapping is enabled, as each brush snaps individually to the grid. Snapping should happen relative to the entire group, not individually.
Where can I download it?
If people want I can also make an OSX version available but I don't have any experience running those applications outside of the IDE environment yet, so it may require a bit of research and testing for me to get it working.
What sort of feedback would be useful?
Any feedback, positive or negative, is much appreciated. I've been coding this for so long that I've lost any semblance of objectivity, so I really do need opinions of genuine users in order to know what works and what doesn't.
Specifically, the following are helpful:
- Bugs - If you find anything that blatantly doesn't work as it should, let me know what it is along with the circumstances and steps to replicate it.
- Comparisons against Hammer - Are there things you think the editor (even at this very primitive stage) does better than Hammer, or things that Hammer accomplishes more efficiently?
- Functionality/usability - Are the editor functions straightforward to use? Are they frustrating? Even at this early stage where the operations are purely utilitarian, it's useful to know in what direction to proceed with regards to the most efficient way to translate user input into editor operations.
Finally, just throw stuff at the application and see what crashes it. Let's stress-test this.
Last edited: