HOW DO I ****ING IMPLEMENT IT AND USE IT

DO WANT

YouTube is blocked at work - any chance you could pm me that video?

what do you mean

You posted a youTube link - I presume of you app in action from the comments that followed. As youTube is blocked at my place of work, I can't view it. I would like to see it, so was hoping that you could send me a copy of the video file via some medium.

Unfortunately I don't really have anywhere to host it. Are there any video sites that aren't blocked?

I've just checked, and Google Video is okay.

Google Video has a pretty long wait time. Are there any other services that will work?

Well, I won't get a chance to work on it again until next week but I added frustum multiselection today.

Sorta. I want to give the user as much information as possible without it being too obtrusive. I don't know if you can see them in the videos but there are also grid axis direction indicators.

The grid in most editors do a very poor job of illustrating grid alignment, which is the whole point they exist in the first place. Especially a JED-like grid which uses dots instead of interstitial lines. It also serves as a local indicator for the direction to the grid axis lines and the grid normal vector, and as the cursor indicator for when you are snapping to a vertex (something else that JED does poorly - you never know for sure what vertex your cleave is snapped to until you've started it)

That's pretty much the idea behind the grid already.


Can you give me a good description of how the push/pull tools work?



That's precisely it - I care a lot more about the project than I do about the source code.

There's really no excuse for wanting to fork a project. It means you're either deliberately trying to keep your improvements to yourself, or it means you're simply too lazy to submit a diff, or you think you're so important that other people should have to track your changes down for you. I'm sure nobody would care if some random guy forked a project like KDE, but when you're talking about a tiny project where the contributions of a single person can be massively significant, you're looking at a lot of wasted effort and a significant fragmentation of the user base. Forking a small project can destroy it.

Forking is what makes open source so weak and crappy. Proponents like to argue that it's a strength but it isn't - even a minor amount of refactoring (by either team) will make the projects too different for cross-porting to be practical. I like to release my source code so people can learn from it and make other use of it, but I hate open-sourcing my projects for these reasons.

Unfortunately there's very little inherent value in any of the code in the editor - all of the math is exceedingly well-documented and if you know enough about software to know about the MVC pattern there isn't a lot you can learn from it. The value of the editor is the project. The problem is that I have absolutely zero interest in changing the project to support JK resources, I don't want that code in my 'fork' of the editor, but if I give the project to other people I would still like to get some benefit from their work in exchange. Can you suggest a way to do this?



The texturing in the editor right now is fake (it just aligns the texture to surface vertex 0 and edge 0). When I get around to implementing texturing a cleave won't affect alignment at all.

It's best to watch the SketchUp videos. The basic tutorials explain the best of SketchUp's features. You might want to try it out, too.

I agree with you about forking projects. Although I suppose it makes sense if you're going to fork it into something completely different.


I actually was going to ask about that. The code itself doesn't interest me as much as your methods. If I started a modeling tool this very day, I would have to start with a tutorial on click detection in 3D space. I don't know that much about advanced geometry. The only strength I've ever had in math has been with discrete mathematics such as set theory.


Could you make your editor a component of some sort? Why not be able to drop it into any 3D tool? Supporting things like sectors or brushes, at least in terms of the game, would just be handled outside the component.

I suppose the trouble there is that to effectively provide interfaces for different applications (even if they are just different GUI toolkits like Winforms or GTK), you'll need an extra layer of abstraction.

Or when the project's maintainers will not accept patches and feedback that is otherwise supported by the majority of the application's users.

The editor looks pretty nice. Pardon my ignorance of C#, but how do you render the viewport? Is it with DirectX calls or via some primitive graphics API in C#? I have done simple 2D editors in Swing/AWT and I found the API to be pretty terrible (not to mention that the performance was not fantastic either).

...

Dumb asses. I never wanted to fork any of Jon'C's projects in the first place. All I wanted to do with Sith 2 was write the ****ing AI, but in your usual ignorant fashion you all flamed me to hell. And look what happened to that project.

And, honestly, Sith 2 was a mess. I would have been better off starting from scratch than trying to fix that code.

It's not a matter of ignorance, it's a matter of Jon`C not liking you.

That is pretty slick. One thing I'm not quite following is what defines where you're clipping to. It seems that when you rotate to a free view at 18s, you're not clipping to the grid, which is still in the XY plane as far as I can see, but the indicator lines suggest you're clipping to something in the XZ plane. Did I miss something? (The quality of the GV clip isn't great, so I may well have done).

I wouldn't call it advanced. Computational geometry is by far my weakest area and I'm still not having much trouble with the math. If you have a decent handle on linear algebra you shouldn't have a problem.

It would never be a drop-in sort of thing. I could turn much of it into a form and expose interfaces for game-specific stuff, but that would be a lot of work and what I'm really aiming for is a lightweight in-house tool.



Everything is rendered with XNA, which is essentially a C# wrapper of DirectX.



The grid works exactly like it does in JED. What you're probably seeing is the grid normal indicator (which is cyan).

But what about making available just the computational portion of it? Let the user worry about drawing things. Just expose editing features through interfaces.

that would make modeling a lot of fun, lol

brushes and multiselection

But the computational part of it is the easy part.

Brushes? BRUSHES!

I JUST DONT KNOW ANYMOrE

i c dflt

Sectors AND brushes? Neat.

you c dflt, i see POTENTIAL! this is fricken SWEET!

What games could this be used for?

....games that have 3D geometry in them?

yeah jon'c is pretty much a hero.

this just better work on my mac so i can make some content

<3

When I was editing unreal tournament I would have killed for a jed-like editor that supported brushes, and now it's here. Oh and I notice you've got layers there too. Must have come naturally with the multiselection.

What's that big yellow "60" in the upper left corner of the last pic? Framerate or something?

Do you plan on making it extensible? Import/export plugins? Entity type definitions? stuff like that?

All of the rendering and the UI code are abstracted heavily. It wouldn't be hugely difficult to write a Cocoa# port, but it's not something I'm planning any time soon. I'd rather opensource it (after making a game) and let the community worry about it.

I run Fraps.

The plan for extensibility is going to be compiling C# code at run-time. The editor is already built around an extensible architecture so adding support for external tools would be extremely trivial.

Oh God Jon`C is working on a new awesome thing. But will it ever be finished or will it join Sith 2? ;_;

Also those status messages up in the window might work better in the statusbar? Since, you know, that's what statusbars are for... your "more visible" argument is ok, as long as you give them a black outline so it doesn't disappear on sold white. The option to show that text in the window or on the statusbar would be welcome... I myself would want maximum space for 3d.

For the map layer toggling thing you might want to use a CheckedListbox instead. Or add checkboxes to the ListView instead of a separate column. Or something. One trick I use for checkmarks in a ListView is to set the ListViewSubItem's font to wingdings or something and use a checkmark character. Looks nicer than an X. But I use that when I need multiple checkmarks per row... in your case, a CheckedListbox would work better methinks.

I have other stuff I want to work on first, but the plans include everything you mentioned. I've tested the status information in the status bar and it doesn't work well at all - like I said, the tool context is given to you by the status information. At some point I'm going to be replacing XNA's text rendering with the technique detailed in Valve's SIGGRAPH whitepaper which allows for (among other things) free scaling of bitmap fonts and free outlines.

I also have to 'fix' (read: rewrite) Microsoft's property grid because it doesn't handle multiselections properly.

Really? Multiselections work OK when it's used in the Winforms editor... maybe you just need some special attribute somewhere to change multiselect behavior?

It's a pity, PropertyGrid is an control. I was making a Dark Forces editor at one time but I stopped cause I knew I couldn't pull it off right since I didn't know how to do 3D stuff or even simple hit detection for clicking in a 2d map view. I actually just popped a PropertyGrid right in there and it was working pretty nicely. Never got far enough to try multiselection though.

The problem is that it returns null for new and previous values during the changed event and it doesn't have a changing event. The only solution I can think of is to store the state of every property any time the selection changes...... and I'd rather not do that.

VS uses data binding and some built-in database/transaction/object persistence tomfoolery for undo. Take a large level and change texture names three or four times and you're out of RAM.

what

are you saying that valve invented something

I call bull**** on that, sir

I wrote an undo history system that manages simple objects containing the action data and invokes either a do or an undo event according to changes in the history state. It requires you to implement handlers for each type of event (no automatic 'state' changing) but I find it simple and straightforward to add to an application. I can send it to you if you like.

Thanks, but I already have something like that. The problem is a deficiency with the property grid.

Um... .NET uses On<PropertyName>Changed protected functions that fire whenever the appropriate property is set. You should be similarly implementing this functionality in the class, not the property grid events. Granted you might want separate behavior if you set it from the property grid than if you set it from code, but there are a number of other solutions that will work fine (Browsable(False) properties, a public function, a separate constructor... ie to change the FontStlye in a Font).

[Edit: Oh I didn't read far enough... you want to implement Undo/Redo. Yeah I see your problem now... bleh. You could, in theory, call a function from every property setting which will take care of adding to the undo chain but then you have to have some sort of check to make sure the property's not changing from code... and it would be messier than your solution, if it worked. :(]

I've been refactoring. Making it easier to expand, making the workflow smoother, improving performance and making it so people who are used to a certain other editor can pick up this one faster. Builder brush yes, widgets I haven't decided about yet.