GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion

[radorn]

I'm giving a try at importing a simple sample map into GE, just as a first attempt, and have hit a huge problem, at least huge for me.

Some of you may remember I'm using Sketchup as the modeling program.
One "problem" this editor has is it automatically "etches" new vertices if an edge happens to touch an existing vertex (even if they just get near enough), breaking that edge in two or more new edges, and hence making the subsequent tesselation of the affected surfaces spawn more triangles than I intend to have.

To contain this, my strategy is making subgroups, because grouped geometry is no longer affected by the outside.

To my dismay, the obj import in GE doesn't seem to parse subgroups, or maybe just the first one on the first RoomXX group.
So, to put it in resume, and if I get it right, Each RoomXX group HAS TO contain a single mesh, right?

Can this be changed or do I need to use another 3D software? (at least for a final clean before converting to obj)

[SubDrag]

I'm not sure what you mean? If you have g Room 01, g Room 02, etc, and convert level as Rooms, it should separate into rooms. But I'm not sure what you mean by etching new vertices if it happens to touch?

[radorn]

I'm talking about the constraints of the 3d editor I use, Sketchup.

The GE Editor seems to require that there are no subgroups under the RoomXX top-level groups. RoomXX can only contain a single, unique mesh and no subgroups in the hierarchy.

Imagine this:

OBJ File:
|-[Room01]
|...|-Mesh
|...|-[subgroup1]
|.......|-Mesh
|
|-[Room02]
....|-Mesh
....|-[subgroup2]
........|-Mesh

The meshes contained in RoomXX top-level groups show, but anything in second-level groups in the hierarchy is ignored and won't be converted.

This is a problem for me because of the way Sketchup works, which forces me to group/isolate certain parts or the mesh from each other to avoid sketchup "infering" more surface divisions (and ultimatelly, tris) than I intend there to be in places where vertices touch an edge or an edge intersects a surface.

EDIT: the forum didn't properly display the ascii graphic I made so I had to substitute spaces with periods

[SubDrag]

Yeah everything under Room XX is treated as room XX until the next Room XY is received. I'm not sure what you wanted it to do though?

[radorn]

I want clhildren groups of RoomXX to be parsed as part of the group too.

I really don't know what else to say to try to explain this, man, I really think it's not that complicated.

In my experience
/Room01/Mesh1
/Room01/Mesh2
/Room03/Mesh3
etc
are all converted correctly, since they are under a top-level group called "RoomXX". All fine here.

BUT, if I happen to have something like
/RoomXX/subgroup/Mesh
anything under "subgroup" or other similar second-level (and beyond) groups, it won't be converted.

This wouldn't be a problem if it wasn't for Sketchup's unconvenient behavior under certain circumstances, which I solve mainly by making subgroups. But then, these subgroups will be ignored by the editor's converter...

[SubDrag]

I'm kind of confused as to why that occurs - it must be the format inside the .obj file. Can you post the .obj files and show me? I'll try and fix it.

[radorn]

www.xente.mundo-r.com/radorn/bobomb.zip

These are the .obj files, just putting this in here for those confused - Skorpion
I was already in the process of editting the post - radorn
lol alrighty then. should have waited a while. ill do that next time. - Skorpion
No problem my friend, just couldn't resist doing this color commenting thing -radorn

(ADDED: Sketchup file group hierarchy for comparison with OBJ scheme below)
bobomb.skp
|-[Room01]
...|-[cuadro]
...|...|-Mesh1
...|-[suelo_alfombra]
...|...|-Mesh2
...|-[techo]
...|...|-Mesh3
...|-[tarima]
...|...|-[pasamanos]
...|...|...|-Mesh4
...|...|-[pasamanos]
...|...|...|-Mesh5
...|...|-Mesh6
...|-Mesh7

g Mesh1 cuadro Room01 Model
g Mesh2 suelo_alfombra Room01 Model
g Mesh3 techo Room01 Model
g Mesh4 pasamanos tarima Room01 Model
g Mesh5 pasamanos tarima Room01 Model
g Mesh6 tarima Room01 Model
g Mesh7 Room01 Model

Only the last group is imported.

It seems that this is how Sketchup translates it's grouping scheme to OBJ.
If I edit the Mesh* numbers and delete the g line in all of the groups but the first, it works, but it can be very tedious in a big level.
Couldn't you "fix" the importer so it will ignore all group name information but the Room** number just before "Model"?

BTW, for anyone interested in using these models for something:
You should edit the mtl file and remove the Ka Kd and Ks lines which are related to color information because sketchup does some strange with materials pre asigning them a color shade even if you don't shade them directly, which is then exported to OBJ too and gives it a diferent aspect.
I have reuploaded the file with the modifications, so this note is for those that downloaded before the update. Or you can also download again .

[SubDrag]

Ah, now I get it. It's because g Something Room XX, and I am only looking in the beginning. I will edit the editor to just pick up Room XX anywhere in the line.

[radorn]

Thanks, SubDrag!

Still, the more I look into this, I discover that there are some other problems that may appear once that's done.
For example. If I hand edit the obj file to remove subgroups from the RoomXX groups (effectively "exploding" them, mixing it's contents with the main mesh), some material problems may appear.

In in the short-middle term I should learn some proper 3d editor which lets me forget about this grouping technique I need to do in Sketchup. If not to use it for the whole process, at least as a a tool for the fine work once the main body of the level is done in SU, wich is really fast and nice.

Also, I see myself needing proper UV mapping too. With SU you can plaster a texture over any surface and adjust it perfectly, but if you move something after that, the textures warp. It seems they are not really UV mapped in the sense that vertices don't seem to carry the coords with themselves, or at least lose them at the slightest attempt to move them.

I feel a bit guilty for making you work on this if it will take too much time away.
Maybe you could make a sort of user configurable importer and so anyone can adapt it to whatever his modeler outputs. Just throwing an idea.

[SubDrag]

I've been wanting to open up my editor to external DLLs, but I never quite saw the code for that - you'd think a Dynamically linked dll would be easy, but I need to look around and figure it out.

I'll hopefully get to this within a week or so, but it sounds like you need a new program anyways.

[radorn]

no no, I didn't meant dlls for new formats, but configurable parsing of OBJ files, so the user can adapt it, for example, to the group naming scheme a given modeler outputs, or setting a flag for merging colliding vertices from subgroups' meshes with the main RoomXX. Stuff like that. A simple text file configuration solution would be more than enough. It could even be implemented in the obj importer itself and the configuration strings for it would go the obj-file as comments.

Anyway, yes, whatever comes out of this, I'll still be needing a new 3d editor...
Any suggestions?

[SubDrag]

I think people use Blender since it's free. A lot use Hammer but that's not quite the same.

[radorn]

Hammer is not an appealing option for me, for many reasons. I respect it and I'm happy that it works for many users here, but it's not for me.
I briefly tried Blender recently, but was put off by it's interface. It will require a lot of reading and practicing for me to even start doing anything with it.
It is also very slow in this computer, which severely affects it's responsiveness, mostly because it doesn't use a native windows interface, but rather a wrapper or bridge library, whic adds a lot of overhead and makes it unstable here. It's my computer's fault, yes, but programs with higher degrees of nativeness run exponentially better for me.

I was thinking about older versions of stablished 3d software, like 3d studio max, maya and the like (just know the names, I don't know much about them, that's why I seek recommendation) . I mention older versions since newer versions increasingly focus on newer rendering techniques, primitive types, hihg detail stuff, which is totally out of place for ge, and would only help to make it impossible to run them on my computer. I tried a free trial of 3ds2009 recently and it was a nightmare.
Of course I'm open to other suggestions since I don't know much about what's available out there and just searching in google returns an overwhelming amount of options.

[Dragonsbrethren]

If I could find a piece of free 3D modeling software with a decent interface I would use it over Hammer any day, simply because it would eliminate about five steps needed to make a map, but there isn't any. If there is, I haven't found it yet. Everything is so over complicated and not geared towards making simple, low poly maps quickly. Hammer's strong point is its interface, it took me maybe a day to learn it (back when it had a sloppier interface than it does today, actually), and I've been looking for a "real" 3D modeling program that works like it since. I especially like how it compiles maps based on what you can see, rather than forcing you to model them that way.

I wasn't trying to sell you on the program or anything, by the way. I'm actually hoping someone sees this and directs me to another program that can actually do the same things.

Edit: By the way, this is the closest I've found. Unfortunately it's crippleware that can't save, so I can't say how well its maps will work in GE, not to mention it can't export to .obj directly so there will still be at least one extra step to map creation. I'm not about to buy an $80 program just to find out it's worthless for what I want to do with it.

It might have an option to do some sort of compiling process when saving, but since that option isn't available in the trial it seems as though you need to manually delete anything that isn't visible, and you can't do things like overlap two brushes and let the compiler take care of separating them. This is why I like Hammer, I don't need to worry about those sort of things.

[radorn]

There are many reasons why I don't like hammer. Mainly they are direct consequence of it being an editor for a fundamentally different game.
I have nothing to say about the interface as I have not really used it. I tried to set it up and after not being able to do it as fast as I would have liked, I desisted. You could say I'm lazy, but there are far more powerful reasons.
What I'm about to say are just my views on it and the reasons for me not to use it, which in no way mean anyone should stop using it. I have to repeat that I mean no disrespect to it or anyone using it. It has proven an effective and productive way of producing new levels for many, which validates it above any other considerations.
That said...

I have an unusual way of doing most things and one of them is I need to thoroughfully understand the rationale and main technical details of anything before I really feel like actually using it. Being like this, I have not used Hammer, but I have read about it and about half-life tech. One of the most prominent aspects of it all is how HL and, hence, Hammer work with something called BSPs, which, as the game is concerned, are a way not only to construct a threedimensional space, but to locate objects within it, and determine visibility related stuff.
These "brushes" are not just plain 3d geometry, but contain space partitioning information and are integral to the half life engine.
To use hammer you have to deal with it in the way hammer/hl deal with it, but all that is totally irrelevant to GE. In the end, after working hard to set the environment and satisfy all of HL's needs, you strip out all that stuff, and generate a plain 3d mesh of just ONE aspect of all the work you did. Well, not my cup of tea.
But that's kind of a fundamentalistic approach.
A more important matter is how hammer (or maybe the BSP to OBJ converter, I don't know) breaks down your "brushes" in a myriad tris that take up both space and processing time in a platform such as the N64 which doesn't exactly have them ins excess.
I fell the urge to optimize things, even down to manual triangulation of surfaces in order to ensure the minimum tris possible and also avoid there being too many edges converging on a single vertex, which may lead to problems.
In the same line -but I'm not too sure if this is true or if, while being true, it's corrected in a later step in the process- I have observed that OBJs obtained from hammer levels tend to have convex/"solid" walls (like bricks), even where you would only have needed a simple, single-sided surface to achieve the same visuals, which means not only you are using a lot more tris than needed, but also that many of them (in some cases even the majorty) are left out of view, but they will still be rendered, wasting precious resources.