I dunno, split each face into an individual plane with the material applied? That'd get messy, perhaps do it behind the scenes? This is way over what I'm capable of though. Perhaps if we can just get the CTD to implement uv maps into spark .level files then this whole thing can be avoided entirely.
I dunno, split each face into an individual plane with the material applied? That'd get messy, perhaps do it behind the scenes? This is way over what I'm capable of though. Perhaps if we can just get the CTD to implement uv maps into spark .level files then this whole thing can be avoided entirely.
I can't just split each face into an individual object, because then that defeats the whole purpose of being able to edit it in Blender.
Spark shouldn't have UV maps. It would be MUCH more work than it's worth, and would likely never be used.
My goals for the next update of this are to 1) create an importer, 2) support textures import/export, 3) possibly add an alternative "import/export" method that reads off and writes to the windows clipboard so that you don't have to have extra intermediate files clogging up your workflow.
The only thing currently preventing me from going through with this is I have yet to figure out an elegant way to store texture data PER FACE in Blender.
See, here's how the problem breaks down: In Spark, a face's texture contains 6 properties: Scale X, Scale Y, Shift X, Shift Y, Rotation, as well as the material that is assigned to it -- I'll be referring to this as "Spark tex params" from now on. Blender maps textures to faces using UV coordinates, not the 6 properties listed above. Converting from spark tex params to uv coordinates isn't much of a problem, it's converting BACK that will be the real issue. So, I'm thinking the way to go is to have each face retain its spark tex params, and have it re-calculate the projection any time that face is changed. This presents two problems: 1) how to store per-face data without preventing users from modifying the mesh, and 2) how to get Blender to report any mesh changes so the textures can be updated??? The UV project modifier is great, but it doesn't work per-face! So in order to get that to work, I'd have to split a mesh into individual faces, but that leaves our workflow even worse-off than we were in Spark! So what about storing per-face data separately, and matching it up to face IDs later? Well... what if the user modifies the mesh? That doesn't work then...
So I'm opening the floor up to suggestions here... because I'm out of ideas.
maybe export props from blender. Now the Spark Blender Exporter exports only geometry (which is fine) and having props (even without collision) would do some good in there.
My goals for the next update of this are to 1) create an importer, 2) support textures import/export, 3) possibly add an alternative "import/export" method that reads off and writes to the windows clipboard so that you don't have to have extra intermediate files clogging up your workflow.
The only thing currently preventing me from going through with this is I have yet to figure out an elegant way to store texture data PER FACE in Blender.
See, here's how the problem breaks down: In Spark, a face's texture contains 6 properties: Scale X, Scale Y, Shift X, Shift Y, Rotation, as well as the material that is assigned to it -- I'll be referring to this as "Spark tex params" from now on. Blender maps textures to faces using UV coordinates, not the 6 properties listed above. Converting from spark tex params to uv coordinates isn't much of a problem, it's converting BACK that will be the real issue. So, I'm thinking the way to go is to have each face retain its spark tex params, and have it re-calculate the projection any time that face is changed. This presents two problems: 1) how to store per-face data without preventing users from modifying the mesh, and 2) how to get Blender to report any mesh changes so the textures can be updated??? The UV project modifier is great, but it doesn't work per-face! So in order to get that to work, I'd have to split a mesh into individual faces, but that leaves our workflow even worse-off than we were in Spark! So what about storing per-face data separately, and matching it up to face IDs later? Well... what if the user modifies the mesh? That doesn't work then...
So I'm opening the floor up to suggestions here... because I'm out of ideas.
maybe export props from blender. Now the Spark Blender Exporter exports only geometry (which is fine) and having props (even without collision) would do some good in there.
I may be mistaken, but I think the real speed advantage in using props vs geometry only comes into play once you start using a lot of instances... and having 1 instance of every prop might actually be slower than just having the geo in there... could be wrong about that though, just a gut feeling here.
The geometry is occluded face by face while props (if done properly) are occluded using a dummy box (faster by far that way).
Video cards like repetition and re-use of things (instances) and it saves memory on the PC (not the GC). The things is that the usual props are more complex (as a 3D mesh) than any usual geometry we can see in maps. It's still faces to draw on screen. So it's usually more faces and obviously it takes more GPU time.
Official maps do the same. Simple geometry and the use of a lot of props. Refinery and most of all Eclipse are example of this kind. Of course you can to 100% geometry in a map but it won't go far concerning little details and stuff. Props are made for that.
It is better on many level. Rendering is the least. Take any other game, same concept. Terrain/geometry + props. FarCry TES: Morrowind/Oblivion/Skyrim, Crysis, Mass effect and so on. It allows to use and reuse the same object over and over (who said Veil???) with no difficulties. Pipes, fences, etc...
If used in a proper and balanced way, it does the trick. Mineshaft or Kodiak wouldn't be as good looking as they are without any props like rock, boulders and such.
The geometry is occluded face by face while props (if done properly) are occluded using a dummy box (faster by far that way).
Video cards like repetition and re-use of things (instances) and it saves memory on the PC (not the GC). The things is that the usual props are more complex (as a 3D mesh) than any usual geometry we can see in maps. It's still faces to draw on screen. So it's usually more faces and obviously it takes more GPU time.
Official maps do the same. Simple geometry and the use of a lot of props. Refinery and most of all Eclipse are example of this kind. Of course you can to 100% geometry in a map but it won't go far concerning little details and stuff. Props are made for that.
It is better on many level. Rendering is the least. Take any other game, same concept. Terrain/geometry + props. FarCry TES: Morrowind/Oblivion/Skyrim, Crysis, Mass effect and so on. It allows to use and reuse the same object over and over (who said Veil???) with no difficulties. Pipes, fences, etc...
If used in a proper and balanced way, it does the trick. Mineshaft or Kodiak wouldn't be as good looking as they are without any props like rock, boulders and such.
Props are good for the mappers diet.
So... we're in agreement? :?
I've actually thought about making an external tool for spark that would be like a one-click "make prop out of geo" feature that'd automatically take what's in the clipboard, and generate a DAE from it and run builder. That'd take quite a lot of effort, and I think I'd need to use python for that, instead of Java (Java, it seems, cannot read raw data off the clipboard... it's got to either be plain text or you have to use some special Java libraries)
woooooooooooooooooow, this is so cool. so you tell me i can make a whole level as .obj and then import it to blender and export it as .level file? you magician, you. guess i might go to work right away? cause honestly i dont really like the editor. ok, this must hurt whoever designed this and it is a good thing for one man or two or however many designed this, but whatever your preferred 3d app is, is gonna be alot more productive at this i think. so i definitely want to craft this way.
but what is it exactly you can do right now? is it "only" geometry or does it also include materials? what would be the way to go about this?
and another thing: it is good to hear that 1 blender unit is 1 spark unit, but can you also import ns2 maps or meshes into blender at the correct size? i recently tried this with the map editor and there was no button for an exporter, so i took a look at the gorge model, but it was .max and by the time it gets to .obj imported into blender (no idea about settings, should be all vanilla) it is quite large. so i guess i could somehow figure out the size of a marine and scale it approx, but it is probably not as elegant as being able to import it right away.
anyway this is what i kinda scaled it to:
In future put any large images behind spoiler tags - Mouse
woooooooooooooooooow, this is so cool. so you tell me i can make a whole level as .obj and then import it to blender and export it as .level file? you magician, you. guess i might go to work right away? cause honestly i dont really like the editor. ok, this must hurt whoever designed this and it is a good thing for one man or two or however many designed this, but whatever your preferred 3d app is, is gonna be alot more productive at this i think. so i definitely want to craft this way.
but what is it exactly you can do right now? is it "only" geometry or does it also include materials? what would be the way to go about this?
and another thing: it is good to hear that 1 blender unit is 1 spark unit, but can you also import ns2 maps or meshes into blender at the correct size? i recently tried this with the map editor and there was no button for an exporter, so i took a look at the gorge model, but it was .max and by the time it gets to .obj imported into blender (no idea about settings, should be all vanilla) it is quite large. so i guess i could somehow figure out the size of a marine and scale it approx, but it is probably not as elegant as being able to import it right away.
anyway this is what i kinda scaled it to:
In future put any large images behind spoiler tags - Mouse
Currently, the exporter will only export the geometry, and all textures are set to the 1024 dev wall texture, with shifts and rotation zeroed out, and scale set to 1.0, 1.0.
Typically, my workflow is to use the editor for as much as possible, but sometimes there's tasks that Blender is better suited for (ie booleans). My workflow is to copy all the geo I want to bring into blender, paste it into a new editor instance, use "save as" and change the file type from ".level" to ".obj". Use the blender importer to import the obj, THEN, scale it up by exactly 39.37 (39.37 inches in a meter... approximately, and EXACTLY what the editor uses). THEN, you'll notice it's all rotated to compensate for the different coordinate systems, so I like to use Ctrl+A -> Rotation & Scale to apply the transformations to the objects. Everything will look huge in Blender, that's normal. You may need to modify the viewport camera's draw distance to prevent the objects from clipping once you zoom out enough to see everything. ( 'N' to open Properties panel, 'View' dropdown, find "clip" and set "end" to a larger number (I use 10000)
OOkay, NOW you do whatever you want to do in blender, then when the time comes to export, use my spark .level exporter.
NOTICE: I just realized recently that I screwed up when writing the exporter... you'll need to join ( Ctrl + J ) all of your meshes, because it'll only export one mesh at a time, even if you have more than one selected. Oops!
Also: to clarify: "1 blender unit is 1 spark unit" ONLY if, when exporting with my exporter, you have "Unit Correction" checked (on by default).
I've toyed with the idea of re-writing the exporter, and writing an importer, to create a fully-functional spark geometry and materials editor within blender. It'd be a ton of work, and it still wouldn't be completely self sufficient (as it would be impractical and currently... impossible to import props and cinematics into the editor, not to mention the light rendering techniques are probably NOT the same and it would take quite a bit of work to figure out how to get the two to look similar enough). Though it would be a HUGE help as far as texturing is concerned.
The biggest obstacle to THIS happening, is figuring out how to preserve the texture data in Blender so it's the same coming it as it is going out. See, spark defines material settings PER FACE, whereas blender defines material settings PER MESH. Spark defines texture coordinates by calculating the surface normal, rotating/scaling/shifting the texture about that. Blender defines texture coordinates through UV mapping... VASTLY more robust solution than spark. I can pretty easily convert the spark material mappings into UV coordinates. The big problem is, when exporting, how to get them back!
I've had a few ideas about how to solve this problem. The first, is to create a new material for every face, and perform the rotation/scale/shift operations inside the material through nodes. Yea that'd technically work, but it'd be a huge pain in the ass to write that in, and it would end up being more of a hassle to edit the textures in Blender than it would to just stay in Spark. So that solution is out. My other idea, and the one I'm currently leaning towards nobody is reading this is to convert to UV coordinates upon importing into Blender, then to export, I'll have to figure out a way of converting the UV coordinates to the spark mapping parameters... tricky part is what if there IS no good conversion? Like what if some smart-ass makes a square plane's uv coordinates look like a trapezoid? Spark can't emulate that, so what do I do? My answer to that is... deal with it. If the UV coordinates are so horribly distorted that they can't be adequately converted back to spark mappings... chances are they look bad anyways, so I couldn't care less.
Another small little caveat with importing to Blender is you'll lose any embedded edge loops you've created. What do I mean? I mean if you open up spark, draw a square, then draw another square inside of that square, you'll have two faces: a middle square, and a square with a hole in it. Blender can't do faces with holes in them, so that'll have to be converted to Blender's more mainstream N-gons. I don't have a clue where to being solving that problem. What problem? Well, see the vertices and edges will import just fine, but how do I go about dividing up that donut shaped face so that the new face doesn't end up crossing over the hole that's supposed to be there? New edges will HAVE to be created, but where?
I lied, I DO have an idea of how to go about doing that. I can exploit blender's "curve" objects to make polygons with holes in them, but unfortunately this doesn't work with 3d geometry; it has to be a flat shape. So what happens if a face with a hole in it isn't perfectly flat... what if it's at a 45 degree angle? Sure, I could rotate the curve object 45 degrees, but that makes the math a little trickier, and doesn't solve another problem: what if the face isn't planar? So I figure the solution here is to make the curve object oriented along the plane (xy, xz, yz) that best fits the face, even if it doesn't come close at all (I'm looking at YOU... 45 degree angle wall!). So basically I'll just disregard one axes when creating the plane, convert it to a mesh, then translate those vertices along to their proper positions on the axes that was ignored a moment ago.
There's another big problem though that I haven't yet come up with a satisfactory solution for yet: Layers and groups. I don't have a clue how to store the layer and group data PER FACE. As far as I'm aware, the only thing that is stored per-face in blender is the material it's assigned... and each face can only have one of those (objects can have an unlimited number of materials, though). For Groups, I've thought about just having the object parented to a null, but that doesn't work: grouping is per-vertex, per-edge, and per-face. It would be a limitation to working on the map in Blender. Same goes for layers, although parenting isn't even an option there, as faces can be members of multiple layers. So I really don't have a clue here.
Unless... oh damn it all I think I may have just figured it out...
It does:
-Exports geometry with basic "dev texture" on it.
-Not export all faces (triangle) if your mesh isn't big enough (in blender) as they will be too small in editor (<1 if i remember correctly).
-have some issue with special faces (Ngon) that have a hole for example.
BeigeAlert :
-is working on how to export texture with geometry.
My next question:
How about props file format ? Exporting object even without collision mesh would be THE "must have".
How about props file format ? Exporting object even without collision mesh would be THE "must have".
Props format is never gonna happen. Not from me at least.
@Mendasp did find this, though: http://dev.cra0kalo.com/?p=103 I haven't tried it yet, I don't know how well it works, or IF it works, but worth a shot.
BeigeAlertTexasJoin Date: 2013-08-08Member: 186657Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, NS2 Map Tester, Reinforced - Diamond, Reinforced - Shadow, Subnautica Playtester, Pistachionauts
Coming soon... to a cluttered desktop near you...
You will (soon!!!!) be able to move spark geometry to and from blender... WITH textures!!! All done through the clipboard, so no more file clutter with importing and exporting.
BeigeAlertTexasJoin Date: 2013-08-08Member: 186657Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, NS2 Map Tester, Reinforced - Diamond, Reinforced - Shadow, Subnautica Playtester, Pistachionauts
Aaaaand we're live with the new version. Making a new thread as I suspect this stickied thread doesn't pop up when new posts are made -- it stays at the top where people are accustomed to ignoring it.
Comments
I can't just split each face into an individual object, because then that defeats the whole purpose of being able to edit it in Blender.
Spark shouldn't have UV maps. It would be MUCH more work than it's worth, and would likely never be used.
maybe export props from blender. Now the Spark Blender Exporter exports only geometry (which is fine) and having props (even without collision) would do some good in there.
I may be mistaken, but I think the real speed advantage in using props vs geometry only comes into play once you start using a lot of instances... and having 1 instance of every prop might actually be slower than just having the geo in there... could be wrong about that though, just a gut feeling here.
Video cards like repetition and re-use of things (instances) and it saves memory on the PC (not the GC). The things is that the usual props are more complex (as a 3D mesh) than any usual geometry we can see in maps. It's still faces to draw on screen. So it's usually more faces and obviously it takes more GPU time.
Official maps do the same. Simple geometry and the use of a lot of props. Refinery and most of all Eclipse are example of this kind. Of course you can to 100% geometry in a map but it won't go far concerning little details and stuff. Props are made for that.
It is better on many level. Rendering is the least. Take any other game, same concept. Terrain/geometry + props. FarCry TES: Morrowind/Oblivion/Skyrim, Crysis, Mass effect and so on. It allows to use and reuse the same object over and over (who said Veil???) with no difficulties. Pipes, fences, etc...
If used in a proper and balanced way, it does the trick. Mineshaft or Kodiak wouldn't be as good looking as they are without any props like rock, boulders and such.
Props are good for the mappers diet.
So... we're in agreement? :?
I've actually thought about making an external tool for spark that would be like a one-click "make prop out of geo" feature that'd automatically take what's in the clipboard, and generate a DAE from it and run builder. That'd take quite a lot of effort, and I think I'd need to use python for that, instead of Java (Java, it seems, cannot read raw data off the clipboard... it's got to either be plain text or you have to use some special Java libraries)
Thanks!
but what is it exactly you can do right now? is it "only" geometry or does it also include materials? what would be the way to go about this?
and another thing: it is good to hear that 1 blender unit is 1 spark unit, but can you also import ns2 maps or meshes into blender at the correct size? i recently tried this with the map editor and there was no button for an exporter, so i took a look at the gorge model, but it was .max and by the time it gets to .obj imported into blender (no idea about settings, should be all vanilla) it is quite large. so i guess i could somehow figure out the size of a marine and scale it approx, but it is probably not as elegant as being able to import it right away.
anyway this is what i kinda scaled it to:
In future put any large images behind spoiler tags - Mouse
Currently, the exporter will only export the geometry, and all textures are set to the 1024 dev wall texture, with shifts and rotation zeroed out, and scale set to 1.0, 1.0.
Typically, my workflow is to use the editor for as much as possible, but sometimes there's tasks that Blender is better suited for (ie booleans). My workflow is to copy all the geo I want to bring into blender, paste it into a new editor instance, use "save as" and change the file type from ".level" to ".obj". Use the blender importer to import the obj, THEN, scale it up by exactly 39.37 (39.37 inches in a meter... approximately, and EXACTLY what the editor uses). THEN, you'll notice it's all rotated to compensate for the different coordinate systems, so I like to use Ctrl+A -> Rotation & Scale to apply the transformations to the objects. Everything will look huge in Blender, that's normal. You may need to modify the viewport camera's draw distance to prevent the objects from clipping once you zoom out enough to see everything. ( 'N' to open Properties panel, 'View' dropdown, find "clip" and set "end" to a larger number (I use 10000)
OOkay, NOW you do whatever you want to do in blender, then when the time comes to export, use my spark .level exporter.
NOTICE: I just realized recently that I screwed up when writing the exporter... you'll need to join ( Ctrl + J ) all of your meshes, because it'll only export one mesh at a time, even if you have more than one selected. Oops!
Also: to clarify: "1 blender unit is 1 spark unit" ONLY if, when exporting with my exporter, you have "Unit Correction" checked (on by default).
I've toyed with the idea of re-writing the exporter, and writing an importer, to create a fully-functional spark geometry and materials editor within blender. It'd be a ton of work, and it still wouldn't be completely self sufficient (as it would be impractical and currently... impossible to import props and cinematics into the editor, not to mention the light rendering techniques are probably NOT the same and it would take quite a bit of work to figure out how to get the two to look similar enough). Though it would be a HUGE help as far as texturing is concerned.
The biggest obstacle to THIS happening, is figuring out how to preserve the texture data in Blender so it's the same coming it as it is going out. See, spark defines material settings PER FACE, whereas blender defines material settings PER MESH. Spark defines texture coordinates by calculating the surface normal, rotating/scaling/shifting the texture about that. Blender defines texture coordinates through UV mapping... VASTLY more robust solution than spark. I can pretty easily convert the spark material mappings into UV coordinates. The big problem is, when exporting, how to get them back!
I've had a few ideas about how to solve this problem. The first, is to create a new material for every face, and perform the rotation/scale/shift operations inside the material through nodes. Yea that'd technically work, but it'd be a huge pain in the ass to write that in, and it would end up being more of a hassle to edit the textures in Blender than it would to just stay in Spark. So that solution is out. My other idea, and the one I'm currently leaning towards nobody is reading this is to convert to UV coordinates upon importing into Blender, then to export, I'll have to figure out a way of converting the UV coordinates to the spark mapping parameters... tricky part is what if there IS no good conversion? Like what if some smart-ass makes a square plane's uv coordinates look like a trapezoid? Spark can't emulate that, so what do I do? My answer to that is...
Another small little caveat with importing to Blender is you'll lose any embedded edge loops you've created. What do I mean? I mean if you open up spark, draw a square, then draw another square inside of that square, you'll have two faces: a middle square, and a square with a hole in it. Blender can't do faces with holes in them, so that'll have to be converted to Blender's more mainstream N-gons. I don't have a clue where to being solving that problem. What problem? Well, see the vertices and edges will import just fine, but how do I go about dividing up that donut shaped face so that the new face doesn't end up crossing over the hole that's supposed to be there? New edges will HAVE to be created, but where?
I lied, I DO have an idea of how to go about doing that. I can exploit blender's "curve" objects to make polygons with holes in them, but unfortunately this doesn't work with 3d geometry; it has to be a flat shape. So what happens if a face with a hole in it isn't perfectly flat... what if it's at a 45 degree angle? Sure, I could rotate the curve object 45 degrees, but that makes the math a little trickier, and doesn't solve another problem: what if the face isn't planar? So I figure the solution here is to make the curve object oriented along the plane (xy, xz, yz) that best fits the face, even if it doesn't come close at all (I'm looking at YOU... 45 degree angle wall!). So basically I'll just disregard one axes when creating the plane, convert it to a mesh, then translate those vertices along to their proper positions on the axes that was ignored a moment ago.
There's another big problem though that I haven't yet come up with a satisfactory solution for yet: Layers and groups. I don't have a clue how to store the layer and group data PER FACE. As far as I'm aware, the only thing that is stored per-face in blender is the material it's assigned... and each face can only have one of those (objects can have an unlimited number of materials, though). For Groups, I've thought about just having the object parented to a null, but that doesn't work: grouping is per-vertex, per-edge, and per-face. It would be a limitation to working on the map in Blender. Same goes for layers, although parenting isn't even an option there, as faces can be members of multiple layers. So I really don't have a clue here.
Unless... oh damn it all I think I may have just figured it out...
It does:
-Exports geometry with basic "dev texture" on it.
-Not export all faces (triangle) if your mesh isn't big enough (in blender) as they will be too small in editor (<1 if i remember correctly).
-have some issue with special faces (Ngon) that have a hole for example.
BeigeAlert :
-is working on how to export texture with geometry.
My next question:
How about props file format ? Exporting object even without collision mesh would be THE "must have".
Props format is never gonna happen. Not from me at least.
@Mendasp did find this, though: http://dev.cra0kalo.com/?p=103 I haven't tried it yet, I don't know how well it works, or IF it works, but worth a shot.
You will (soon!!!!) be able to move spark geometry to and from blender... WITH textures!!!
Just got a few more bugs to squash...
http://forums.unknownworlds.com/discussion/136044/blender-spark-addon-for-blender