"Extrude" Function in WED + Moving Camera in 3d mode improvement

Hello,do you will include the famous "extrude" Function with shortkey function in WED? Because it would be nice if this function which is included in MED could be made in WED!

The second thing is:
During the moving in the 3d window in WED every model changes to a bounding box! That really annoys me because i cant set models then to TERRAINS or big smoothed blocks! It would be nice if you could click on a checkbox where you can choose the BBox function or not!
greetings Ness

soon, you will be able place objects using a realtime 3d engine view. see forecast.

Ness,

You should do some research and learn the differences between CSG (Constructive Solid Geometry) and polygons. They are completely different, function differently and, as a result, you work with them differently as well.

CSG is what WED uses to create environments. It is an old carry over from the days when BSP styled real-time 3D engines were what was popular. Most engines do not use BSP any longer and, as a result, polygons are used for level creation. But if you build a level inside of WED you will be using CSG because that is the type of program WED is. So learn the differences and you will begin to understand why EXTRUDE is not a native part of WED, but is a part of MED.

Now MED is NOT a CSG creation tool, but instead is a polygonal modeler. As such, EXTRUDE makes sense there. You can extrude a polygonal face. However, as was pointed out in your previous thread requesting CSG Subtract in MED, MED does not use CSG elements. Therefore, requesting CSG tools in MED would not work.

Now, I realize that this may seem like arguing semantics. What you want is the ability to do something like an extrude in WED. Fine. I can understand that. However, if you learn about CSG then you will better understand WED and why you don't need an extrude feature there.



You can do this already. Go to File and the find Preferences. Once the Preferences dialog appears, click on the Advanced tab. In the second column, make sure Bound Box During Changes is not checked. Also make sure Display Entity Shape IS checked.

However, since A7 now also renders meshes, there's no problem with concave blocks - so why no extrude feature after all?

well i have still problems with concave blocks!
I get an error with NEWEST WED Version about :
MAP DOESNT ALLOW Concave blocks!

Because WED does not build with meshes. It builds with CSG. They are completely different animals. What really needs to happen is WED and MED need to be ditched and a completely new editor that is completely based on meshes (polygons) needs to be created.



That is because you build in WED using BSP correct CSG objects! Study and learn (like I have already said) if you want to understand how this all works. If you want concave blocks, then build your level geometry in a 3D program and import it into WED. WED only allows you to build, in the editor itself, using BSP correct CGS objects.

I switched to "create meshes" and was able to use concave blocks.

so it's "no" to both posts.

edit: I just tried to do that again. WED has no problem with concave blocks if turned on in map properties, but the map builder doesn't seem to like it anymore and delivers crippled blocks. I was sure this was working before, too sad

Well concave blocks are certainly not the problem.

Always when you import a level, you get meshes with lots of doors and windows, they are 100% concave and do not make any problem.

Your problem probably is that your take a block and manipulate its vertices in a way that the result is no 3D object anymore. For instance, take a cube and move one of its vertices outwards. This creates an impossible object because surfaces are bent and then you get errors in the map.

This can not happen with meshes that consist of triangles, because they are always possible.

Then cant WED pop up a different message when that happens?

Instead of the old error message
"Bad manipulation. Map doesnt allow concave blocks. [Cancel][Ignore]"
how about we get a message like
"Bad manipulation. Convert Block to Mesh? [Cancel][Accept]"
That would be much more useful.

Since WED does not convert CSG geometry in to meshes, then this error message would not work because WED could not give you the choice to do that. This is the nature of CSG ... a different animal than a mesh (polygonal, quadratic or otherwise).



The original post was not about A7, but about A7's WED. He wanted an extrude function in WED, but that would belong in MED. Why? Because WED does not CREATE meshes, but instead creates CSG geometry.



Folks, we are getting our terms mixed up here. An imported level containing MESHES is NOT the same thing as building a level in WED using WED's blocks, which are NOT meshes, but CSG geometry. They are different animals. Now that you can import polygonal meshes into WED then, yes, any sort of geometry works in WED, concave or otherwise. But this is not the case for BSP correct CSG elements such as those created Nativity within WED itself.

About the doors and windows:

If this was built OUTSIDE OF WED in a 3D modeling program (be it MED or some other 3D program like 3DS MAX) then you are talking about meshes and concave is fine. However, if you build the level inside of WED using its native BSP correct CSG blocks, then you cannot have concave geometry. However, that does not mean you cannot build a door. A hole in a wall (a door or a window) is NOT concave in the least. It can be built using a series of non-concave blocks.

A door, for example, can be built with three simple, non-concave blocks: one for each side and one for the top, leaving a "hole" where the open door would be. None of that is concave.

I know its a different animal, BUT, since an FBX file is an even different animal, and WED can import them,
surely it wouldnt be to hard for WED to "pretend" to import the block and convert 'just that one' block into a mesh object.
The compiler does it, so why cant WED do it on a smaller scale...

As I said WED has no problem handling concave blocks. It displays and renders them just fine. But you have to turn it on in map properties first, otherwise it won't work. It's the map compiler who is messing up things.
I thought this worked before, but I might remember wrong.
And if WED can handle meshes, why not consider blocks as meshes?

Just because WED used to work with concave blocks only, why still come with that argument? CSG with concave blocks is the past!
Blocks basically are nothing else than predefined meshes. WED should handle everything the same! So should the engine.

I agree, Firoball. I think that WED and MED need to be ditched in favor of one unified editor for creating polygonal environments and other polygonal meshes. Or Conitec could create a decent modeler (or require the end-user to use another modeler) and have a decent, real-time editor for putting it all together (possibly like the one they are in the process of creating now).

However, my point here was not to say that WED should not change, but to point out the fundamental differences between WED blocks and polygonal meshes. If Ness understood the differences then perhaps his request would be different. For example, instead of asking for an extrude function for CSG geometry in WED, he might ask for WED to dump CSG all together in favor of a more modern way of creating game environments such as using standard meshes.



I don't remember, frankly. Didn't it used to take a block with a concave surface and break it up in order to make several non-concave blocks?



Because that would be quite a fundamental change for WED. WED is what it is: a CSG tool. They would have to rewrite WED to do more than import meshes, but to create them and edit them. If you remember, Conitec had wanted to merge MED and WED many years back, but that ball got dropped like a hot potato. So it must not be so easy for Conitec to do this.

I've never heard that WED had problems with concave blocks. 90% of all levels contain partially or mostly concave blocks, so I don't think that there can be a problem.

Still, you have to keep some things in mind:

- Concave blocks can't be used for building the BSP tree by the compiler. So when your level consists of only concave blocks, the BSP tree consists of only one huge leaf.

- When you manipulate blocks to make them concave, switch the map to "concave" in Map Properties to suppress the warning, and also lock their texture and set the block's "Concave" flag. This is not necessary for imported blocks because their concave flag is automatically detected and their texture automatically locked.

- Make sure that when using vertex manipulation on concave blocks, no surface is bent or broken. Otherwise, WED won't complain, but the blocks will look wrong.

For testing I used a pyramid and moved a single vertex closer to the center, in order to get a concave object.
But most likely I forgot to set the concave flag for the block itself. I only switched that in Map Properties.

I'll try again soon.

I also don´t see a future in WED and MED. All the quake legacies... argh! It´s 2009! Going through Gamestudio´s content pipeline and map compiler is a constant painful fight.

<edit>
some annoyances I ran across recently:

• the fbx importers have no custom scale options (which would be important because there aren´t any serious 3D-software packages which use quants and a power of two grid)
• the WED and MED fbx importers seem to scale differently
• the fbx importers have many problems with triangulating n-gons
• mouse picking is horribly broken in WED
• the map compiler is slow and crash prone
• texture filenames are limited to 16 characters
• the fbx level importer still seems to create alpha channels by mistake even if this is supposed to be fixed

I could go on and on...

By the way, I really dislike quants and the power of two grid. It´s not intuitive. Get rid of it. There is no need for it anymore. CPUs have fast floating point units nowadays.

</edit>

On the bright side... Blender 2.5 (which will be released later this year) will have a very customizable user interface which will make it possible to turn Blender into an easy to use level editor. Conitec would just have to open up the WMB format and then someone could write an exporter to WMB.

Hmmm...I don't know-- don't take this the wrong way...just my two cents-- but it would seem like tossing out the baby with the bath water.

I would say that as long as the Gamestudio art pipeline allows artists to create animated props without config files and Wed allows drag and drop behaviors and templates it's shining in its niche. I don't think legacy technology is always bad. I mean look at Doom3 vs Quake -- sure it looked better, but folks didn't like it as much as the old game.

Everyone wants to keep pushing things forward, but at what cost? It seems like right when a product gets bug free, it's tossed out the window and an entire new code logic is created to take advantage of this or that hardware improvement...with new bugs. i.e. Vista

I'm not saying to go back to the Commodore 64 and its software (though a $200 keyboard computer would probably have a market today), but change even for the best is not always good. I think Gamestudio could shine in a sub-niche like Web3D and Augmented reality (or something else) which would get it on another path say than Unity or Torque-- and still be an easy to use engine. Along with all the planned changes it would be a good strategy to differentiate itself.

Again my two cents... I do understand what you are saying and I think we could both agree that anything that makes the engine easier to use and even more versatile is a good thing.

I am not complaining about the engine but more about the tools. In my opinion the engine is quite nice and there isn´t that much missing compared to the competition.

But the tools aren´t user friendly and very outdated. Conitec should start doing some dogfooding. Hire an artist who gives direct feedback or something.

For inspiration Conitec should take a look into the Unity demo once it is out in a few weeks.

I confirm that I forgot to set the flag for the concave block.

It's working just alright.