Topic: Importing to D3Edit from Blender

[(LL)Atan]

Topic split from 'Descent 3 Advanced Tutorials...' and quote added by WillyP

Yeah, but I really don't think D3Edit really needed to be that complicated, and I know there are people out there who agree, or at the very least can relate. Like I said, Blender can do a lot of the same things and more a heck of a lot easier.

And the thought has already crossed my mind to just build it all in Blender then piece it together in D3Edit, as that would be much easier for me. Unfortunately, there is the issue of converting files so that both programs could read them, and the sad truth is that I don't know many means of doing it, at least not with Blender. Granted, I once found a converter program that could do it, but it'd cost me fifty bucks to get the full version just so I could use it, and I wasn't willing to pay it. 

Maybe that can be Atan's next project, figure out some way to get D3Edit to work around that issue...whatever the case, if it can be I would be forever indebted to that person.

if I translate and understand it right, you would like to own an importer tool (D3Edit-function) to read in / convert an blender object (Room) into D3Edit.
And you are talking about something like a room-shell, no objects inside etc. Did I understand that well?
Hm, I must think over that, needs to understand Blender specs first, and as I read a way down: time, lot of time

As for the usage of D3Edit, the day I started with D3Edit, I throw this program out of the window.
It wasn't that what I learned to use, tons of hours before, I mean usage of Devil and DMB II.
I couldn't produce a simple cube, I couldn't make a face and crash over crashes. I just was really frustrated and went back to Devil and D2/D1.

In the meantime we are far far away from such issues. Nearly one click only, and you own your complex room /object structures. And it's easy to put these parts together for a level/mission.
No doubt, this tool needs some time to be ready to handle it well, but it's a very complex tool, containing a lot of functionality you may find in high cost soft only.
On the other hand, it's exactly this what makes D3Edit not easy to use because you need to find out how to use these fine things first.
I try to write some things down and place it at Fischleins, but there comes the time factor into the game again...

But the very basics you may produce in such a short time these days, just give it a try.

[Pumo]

Just as a side note, Pumo Mines' robots, reactors and turrets were made on D3Edit

It's not the greatest interface ever and is not easy either, but when you compare it to Polytron, D3Edit is heaven.

Although I had to use lot of convertors to export the models to D2, it worths it.
All with its ups and downs, D3Edit is a pretty decent program (at least for me).

[Skyalmian]

Heh... I find this site/thread after making this post earlier today...:

The Toshiba mk3263gsx 320GB HDD has Windows 7 on it with only 1 primary partition.
The Hitachi hd20500 500GB HDD that has Arch Linux 64 on it has  4 primary partitions (/boot (ext2), swap, / (ext4), /home (ext4)).

Although I considered it for a long time back in April 2010 when I was getting ready to set up the new Hitachi hard drive, I decided that if I really want to to play games, or do level design and testing for them, I can just swap out hard drives. As of late I've been on the Windows drive for just that reason. I have 7+ year old Descent 3 projects I had abandoned in 2003, zipped into a file, given to a friend, and subsequently forgotten about, until this year. Plus, restarting them but using Blender instead (in Arch of course) and in the process learning said utility would be educational.

Of said project, the first level was 100% finished in 2003, the third was 80%, the second was around 50%, and the fourth was around 10%. I don't remember why it was abandoned exactly, but it undoubtedly had to do in part with 1.4 model bugs and probably being "too lazy" at the time to simply have all custom models match vanilla ones...

Hmm.

In the event that I decide to drop it again, I'll just archive and post everything [needed to recreate / continue it] online this time.

^ I have no issue doing that with Lunar Outpost MN0019 which I was making an "extended" edition of at the same time, but which I don't intend to resume now or in the future. It was more of the same, basically, but in the vein of being more complete to reflect the 30-floor "Lunar Outpost MN0012" mine from the novel Descent.

[SaladBadger]

It's not the greatest interface ever and is not easy either, but when you compare it to Polytron, D3Edit is heaven.

Polytron is an absolute mess and if I get off my butt and actually work on my new set of D2 editor tools, I intend to simply provide export scripts for popular modelers. I don't understand how anyone ever used Polytron, to be honest. The workflow is just senseless.

Using exporters would save many a ton of sanity.

[Skyalmian]

What I'll do for proper scaling in Blender: 1) export the default Pyro-GL model 2) export a perfect 20x20x20 unit cube created in D3Edit. Then scale Blender grid as necessary and use snap-to-grid.

If I remember right "dxf2orf" has this nasty bug where half of all imported orfs have their normals/faces facing the wrong way... I had spent a lot of time flipping faces in D3Edit from that...

[Babylon]

Face normals are perfectly preserved when converting from Blender to D3 Edit.  Just make sure that they're pointing the right way in Blender and they will point the right way in D3 Edit (i.e. turn off Blender's double sided normals so you can actually see which way they are pointing in Blender).  You will want to triangulate your faces before exporting, though; 1) so you don't exceed the 3,000 polygon .orf limit, and 2) because square faces export as triangles, meaning that you will have to rebuild them (easy to do, time consuming in practice).  The only thing strange about the import of a Blender model into D3 Edit is the orientation of the model - it will end up rotated 90^o downward (on its face) and mirrored along the x-axis.  Both are simple issues to fix, though.

The size scale remains exactly the same, so you can save yourself the time of converting the Pyro and importing it into Blender just by knowing the radius of the model (6.79 units, ~7u).  Since Descent 3 does collision detection by spheres, just create a sphere in Blender with a radius of 7 units, and that should serve perfectly as the model to scale your creations by.

...yeah, I think I'll draw up tutorials for all this stuff, and more.  Like seemingly everyone else, the issue will be finding time.  xD  I hate working Saturdays.  :<

[Skyalmian]

I didn't blame Blender there, and didn't use it back then (2003) at all. (Miscommunications.) It must have been the to-dxf export tool I had at the time that exported Descent 1/2 cubes (that's what was used to make all the Descent 1-like tunnels in MN0019), not the dxf-to-orf mention.

The size scale remains exactly the same, so you can save yourself the time of converting the Pyro and importing it into Blender just by knowing the radius of the model (6.79 units, ~7u).  Since Descent 3 does collision detection by spheres, just create a sphere in Blender with a radius of 7 units, and that should serve perfectly as the model to scale your creations by.

Did not know; t.y.

so you don't exceed the 3,000 polygon .orf limit

I definitely remember that; when I hit it several times working on Lunar Outpost MN0019... I don't remember any other limitations; is there a list somewhere?

[Scyphi]

@ Atan: yeah, that's what I'm saying exactly. If you can't pull it off though, that's okay.

@ Pumo: I buy that, I never did figure out how to use Polytron no matter how hard I tried, so I could see how D3Edit would be much better.

@ Insanity Bringer: Yeah, we could use a new set of D2 editing tools. Most of the already existing ones don't even seem to still work on modern systems anymore (at least all of mine don't) including Hoggle, which is a pity, as I loved that program. 'Course, DLE-XP can do the same things already, but hey.

@ Babylon: Wait...you mean to tell me that it's already possible to open up D3Edit files in Blender? How? Last time I investigated this, I was told it couldn't be done unless the files were converted in such a way before opening it up in either one of the programs. I mean, you could open up the file in one program, but not the other, until you converted it into a certain format. And like I said earlier, I did not know of any tools that could make the necessary conversions save one, the one that would've cost me fifty bucks to buy.

@ Skyalmian: I think he was referring to me with those comments.

Now, @...oh no wait, that's everyone, never mind.

[Babylon]

If I remember correctly, the limits of an .orf are 3,000 polygons, 10,000 vertices (64 vertices max per face), and 2600 unique textures.  Someone correct me if I'm wrong.

Yeah, if a converter straight from any of Blender's exports to .orf was made, I'd be happy beyond measure.  The current way I convert is exporting a .raw from Blender, importing that into MilkShape and exporting it then as a .dxf, ending with using the DXF2ORF converter. (Blender -> .raw -> Milkshape -> .dxf -> DXF2ORF -> .orf)  It's a shame that although Blender does export .dxf files, their type is different than the one used by DXF2ORF.  I'm sure there are other methods of conversion around, but I haven't felt like scouring the internet for one when the method I use works well for me.

My to-do list, then:

(Easy) Creating Basic Room Geometry: Working with Vertice/Face Modes
(Easy) Creating More Geometry with D3 Edit's Tools
(Easy) A Guide to Understanding Portals
(Easy) A Guide to Level Textures: Alignment and Lights
(Hard) Terrain and the Geometry Thereupon

(Easy) Importing Custom Assests

(Easy) Creating Textures
(Hard) Creating Animated Textures
(Advanced) Creating Textures with Transparency

(Easy) Creating a Basic Energy Weapon
(Hard) Creating a Missile with Spawns
(Advanced) Creating a Muzzleflash
(Advanced) Creating a High-Rez Beam Weapon

(Easy) Creating Powerups
(Easy) Creating Clutter Objects
(Hard) Creating a Custom Door
(Hard) Creating a Custom Robot
(Hard) Creating Cascades
(Advanced) Creating Breakable Glass (non-scripted)

(Hard) Creating Fake Light Volumes
(Advanced) High Detail Level Lighting
(Advanced) Preserving and Enhancing Level Shadows

(bugs) How to Avoid/Fix "Error: couldn't find a free polymodel"
(bugs) Saturation Washout: What It is and Tips to Avoid It
(bugs) Saturation Washout: Tips to Exploiting It

(Reference Library for Texture GAM Entry)
(Reference Library for Weapon GAM Entry)
(Reference Library for Door GAM Entry)
(Reference Library for Generic Object GAM Entry)
(Reference Library for the Generic Object GAM "Animations" Section)

Let me know if there was anything else that you didn't understand, or wanted to know.

[(LL)Atan]

Here the values I put together over the years.
I'm not 100% sure if all is correct, but it's better than nothing so I believe.
Sorry for the bad formating, I just copy and paste the list.
You may find this and other information at http://www.descent3fischlein.de/home.html -> D3Edit too.
I didn't translate all tutorial and info stuff into English there, just look into, and see what's possible maybe of interest for you. (D3Edit-Users)

Mine:

MAX_LEVELS_PER_MISSION     30
   
MAX_ROOMS                           400   // 0-399 ( Mine rooms )
MAX_PALETTE_ROOMS            50    // max number of loaded rooms (400-449)
MAX_OBJECTS                           1500   // total number of objects in world

MAX_POLY_MODELS            1000   // total number of POLY_MODELS in world

MAX_ACTIVE_DOORWAYS   100   // specific doors inside mine
MAX_DOORS                            60    // predefined Doors useable by Editor
MAX_TRIGGERS                   100   

MAX_PATHS                           100   
MAX_PATH_PORTALS           40   
MAX_GAME_PATHS                   300   
MAX_NODES_PER_PATH           100   

MAX_GOAL_ITEMS                   12   
MAX_LEVEL_GOALS                   32   
MAX_GOAL_LISTS                   4   
MAX_WAYPOINTS                   25   

MAX_SOUNDS                           1000   
      
Rooms:      
      
MAX_REGIONS_PER_ROOM   200   // Facestructures, not connected to room shell
MAX_FACES_PER_ROOM           3000   

MAX_VERTS_PER_ROOM           10000   
MAX_BNODES_PER_ROOM   127   

      
Faces:      
      
MAX_VERTS_PER_FACE           64   

Textures:      
      
MAX_BITMAPS                           5000   // Mine
MAX_TEXTURES                   2600   // Room
MAX_VCLIPS                           200           // OAF
VCLIP_MAX_FRAMES                50           // oaf-Frames
MAX_BUMPMAPS                   500   
MAX_FORCE_FIELD_BOUNCE_TEXTURES   3   // TF_FORCEFIELD
MAX_SPECIAL_FACES           13000   // TF_METAL + TF_MARBLE | TF_PLASTIC
      
Objects:      
      
MAX_MODEL_TEXTURES          35   
MAX_POLYGON_VECS          2500   
MAX_DETAIL_LEVELS          3   
MAX_PROP_LEN                  256   
MAX_NAME_LEN                  32   
MAX_GROUND_PLANES_PER_MODEL   10   
MAX_GUNS_PER_MODEL          64   
MAX_SUBOBJECTS                  30   
MAX_POINTS_PER_SUBOBJECT   300   
MAX_WB_GUNPOINTS         8   
MAX_WB_FIRING_MASKS         8   

MAX_WB_TURRETS                 8

[Skyalmian]

* scratches head in perplexity.

I wonder why Outrage did that... Those values are so low and artificial that they have me wondering why they even bothered going through the process of making them. It would not make sense for them to be specifically for graphical, memory, etc. issues crashing the game due to low hardware, as over time hardware improves and crashes etc. are not 100% preventable anyway. Maybe these were their own in-house development limitations forced into the game and all future additions to...or the Fusion engine is not a very solid one in spite of its advanced state at the time. I still disagree; plain integers with default values such as 32768 or 65536 should have worked fine then, unless I'm missing something 1998-hardware-wise that would be cause for these. Either way, the less limitations, the more active and longterm third party development is over time... What was the cause for 1.4 custom model issues? -- I don't remember exactly but I think it was going over an internal limit caused by the Mercenary expansion filling up most of the slots. If correct, that's one good example.

Here the values I put together over the years. I'm not 100% sure if all is correct, but it's better than nothing so I believe.

Thank you for this list.

[Scyphi]

...or the Fusion engine is not a very solid one in spite of its advanced state at the time.

What clued you in? Sorry, but it's been pretty well know for awhile now that the Fusion Engine has always had it's...issues that the Descent community has just had to deal with for now.

[(LL)Atan]

Could someone offer me one or two descent3 related .blend file(s) for some tests please?

[Babylon]

http://www.wikiupload.com/XYIP4FR5074SXZQ

One is simple geometry, the other is complex geometry that exceeds 3,000 triangles.  Hopefully this helps.

[(LL)Atan]

Thank you, I downloaded the file.
Will take some time to start with that importer. Let's see if I can do that one then, not sure about.