john_smith_account Posted January 13, 2012 Share Posted January 13, 2012 On an unrelated topic, can I get a fix on OZMAV2 please? The 'won't dump maps' bug on some systems is documented by now, and surly it's an easy fix. Either that or a linux compile would make my life a litter better. (I SWEAR I'll learn to compile libraries under linux later.) Link to comment Share on other sites More sharing options...
Jason777 Posted January 13, 2012 Share Posted January 13, 2012 Here is a video of the problem I was talking about, xdaniel. I show how to fix, too, but having to do that all the time would be very inconvenient: I doubt you care about it anymore, seeing as how you plan to rewrite SharpOcarina. By the way, sorry for the long video Link to comment Share on other sites More sharing options...
Arcaith Posted January 13, 2012 Share Posted January 13, 2012 Yeah, that's the one, the Direct-X format. Link to comment Share on other sites More sharing options...
xdaniel Posted January 14, 2012 Author Share Posted January 14, 2012 On an unrelated topic, can I get a fix on OZMAV2 please? The 'won't dump maps' bug on some systems is documented by now, and surly it's an easy fix. Either that or a linux compile would make my life a litter better. (I SWEAR I'll learn to compile libraries under linux later.) I've read about that but never encountered it myself. Is it documented in the sense that you know what's going on? I can't fix bugs I'm not getting myself - I can check for any glaring errors (and can imagine there being some) but beyond that, no idea. A precompiled Linux version I'm not sure about, seeing how I had one posted that ex. didn't work for spinout IIRC... tho that might've been thanks to some missing GL extension availability checks, come to think of it. Here is a video of the problem I was talking about, xdaniel. I show how to fix, too, but having to do that all the time would be very inconvenient: (video) I doubt you care about it anymore, seeing as how you plan to rewrite SharpOcarina. By the way, sorry for the long video Oh, I still care - as I said, I have no idea if that rewrite will go anywhere. As far as I can see, the reason for that is simply that SO does not check if "scene offset + scene data size > room offset". Honestly, I didn't think about situations like that, where the user specifies injection offsets that are very close together. And while I do mention "this does not check if/what gets overwritten in the ROM, yadda, yadda" in the Readme, it's not directly in that context, so it's (yet another) oversight on my end. Will see about fixing that - ex. when such an overlap is detected, giving the user the choice a choice between "cancel injection and let user manually change the offsets" or "automatically inject scene and then all rooms consecutively". Link to comment Share on other sites More sharing options...
SanguinettiMods Posted January 14, 2012 Share Posted January 14, 2012 Can we expect to see spinout's Animating Texture hack implemented into this? Link to comment Share on other sites More sharing options...
xdaniel Posted January 15, 2012 Author Share Posted January 15, 2012 Can we expect to see spinout's Animating Texture hack implemented into this? Better don't expect anything from this for now Besides, tho, I suppose I'll look into it. Already wanted to add support for it in the current SO, but never actually went and did so... Also, new rewrite screenshot, .obj model and material loaders are on a good way: And now I should better go to bed as it's ~4 AM, as I've got to get up between 8 and 8:30 AM again, as I'm going to be dragged to a flea market at 10 AM... Link to comment Share on other sites More sharing options...
xdaniel Posted January 17, 2012 Author Share Posted January 17, 2012 Well, I need some input on a few things regarding the rewrite... First of all, I'm going to abandon my group-based approach to specifying properties like transparency. That stuff is technically supposed to be stored in the material definition, so I'll be doing this how I should've done it in the first place. Texture tiling (wrap, clamp, mirror) will also be set on a per-material basis, plus each material may reference another material from the same material library (calling that "Linked Material", but call it whatever you want), which will be used for multi-texturing, so that you can hopefully finally have stuff like Hyrule Field's grass on your maps. Remember, tho, that I'm still laying the groundwork for all this, so don't get all excited for combiner setups and such already. Groups will still be used for Display List generation, so that one group equals one DList when converted, and collision type definition will also still be group-based, but there won't be any of that "group name in collision must be the same as group name in model" junk from SO anymore. Collision should be 100% independant from any models besides the one you select as the collision model. Next, a question about the material libraries: Which of a material's texture maps should be used as the "primary" one? Ambient? Diffuse? One model viewer expects map_Ka, while the next one expects map_Kd, some exporters only set map_Kd, others use map_Ka. Judging from their names they have different uses, but apparently they're usually set to the same texture map? Honestly, I don't get it, I'm thoroughly confused. Do you have any other lower-level suggestions, things to pay attention to, ex. regarding the Wavefront format or whatever else? But please don't get into Zelda-specific questions and such yet, because even Display List generation is still a good way off, let alone scene or room files. And finally, another screenshot of the current progress with material management... Link to comment Share on other sites More sharing options...
Arcaith Posted January 17, 2012 Share Posted January 17, 2012 The diffuse texture is the colour of the object without light effects. The ambient occlusion texture is a map that shows the shadows on an object if it was evenly lid from all sides (basically it tells us how much a factor ambient light should be on each position). For the purposes of OOT imports, they're more or less the same texture, since I don't think OOT does particularly complex lighting calculations. I believe it just uses vertex colours for ambient occlusion. The GUI is looking very nice Link to comment Share on other sites More sharing options...
Okami Amaterasu Posted January 17, 2012 Share Posted January 17, 2012 Does the OBJ file format have support for vertex colours? I was playing with them in UoT, and I decided they are really cool and that they would be useful. Link to comment Share on other sites More sharing options...
Arcaith Posted January 17, 2012 Share Posted January 17, 2012 Unfortunately not, which is one of the reasons I've been pushing the .x format so much. However, it should technically be possible to implement vertex colour editing in SO, I'm just not sure how you'd go about saving the data, especially if the models' vertex order changes due to revision at any point. Link to comment Share on other sites More sharing options...
Okami Amaterasu Posted January 17, 2012 Share Posted January 17, 2012 Oh. Well, I guess that's too bad. I'll have to learn about the .x format sometime then. Thank you for the reply. Link to comment Share on other sites More sharing options...
xdaniel Posted January 17, 2012 Author Share Posted January 17, 2012 Implementing vertex color editing in SO shouldn't be much of a challenge, but it's not really feasible because 1) effective usage would require manual editing of each and every vertex in the model, which I don't think anyone would want to do, and - even more important - 2) saving them certainly would be a headache and a half. I am thinking of adding support for editing and saving of at least the material library in the rewrite (see the last screenshot), so adding support for the same for the actual model, and, say, adding an additional parameter for vertex colors like "vc" isn't much of a stretch. However said "vc" parameters would only be understood by SO, every time you export a model from ex. SketchUp they'd obviously get lost, etc., etc. Too many pitfalls to work around for too little gain, I think... The .x format is looking like a very good alternative to .objs there, although I haven't looked too much into it yet. How's support for that format in modellers, by the way? Is SketchUp capable of exporting to that, seeing how many people use it as their modelling program? Also, one more update before I'll close VC# for the night, although it's more of an "under the hood" thing: Extended the rendering function list into its own RenderingQueue class with support for giving each function a different priority level out of five. As an example, room models will be rendered first (very high priority), actors come next (normal priority, tho actors don't even exist yet), while the collision model overlay comes last (very low priority). Link to comment Share on other sites More sharing options...
Arcaith Posted January 17, 2012 Share Posted January 17, 2012 Plugins exist for Blender, SketchUp, 3DS Max and Maya. Link to comment Share on other sites More sharing options...
Secant Posted January 17, 2012 Share Posted January 17, 2012 By using this plugin (compatible with the latest version of SketchUp from what I just tested), yes, SketchUp supports exporting models as .x files. Not sure whether the plugin automagically triangulates or how accurate the scaling is, but I suppose that can be worked with on SO's side to correct issues with the raw export. Link to comment Share on other sites More sharing options...
Arcaith Posted January 17, 2012 Share Posted January 17, 2012 Scaling should be 1:1 with the source model unless you specify otherwise in the exporter. Link to comment Share on other sites More sharing options...
spinout Posted January 17, 2012 Share Posted January 17, 2012 re: .x file format, the spec is here. Way more complicated than obj or xml. Though it is more powerful than obj. I'm not sure what kind of licencing it is under, either. *ponders writing a library* Link to comment Share on other sites More sharing options...
The Tjalian Posted January 17, 2012 Share Posted January 17, 2012 re: .x file format, the spec is here. Way more complicated than obj or xml. Though it is more powerful than obj. I'm not sure what kind of licencing it is under, either. *ponders writing a library* You know you want to Link to comment Share on other sites More sharing options...
xdaniel Posted January 19, 2012 Author Share Posted January 19, 2012 (edited) Good to know about all the .x support, I'll take a closer look at it once I've gotten further with the program... Now, as for what I've done during the SOPA/PIPA blackout, take a look: The combiner editor is getting places. It's using SayakaGL's code to (partially) emulate the color combiner and some OpenGL trickery to put the resulting texture back into a Bitmap for display in the material browser. You can change each component of the combiner setup, the raw combiner mux, and select one of currently 6 different presets or templates that cover some typical scenarios - "Shaded surface /w Prim color", "Shaded surface /w Prim color & alpha", "Multitextured, shaded surface", "Multitextured, shaded surface /w alpha", "Unshaded surface /w Prim color" and "Gouraud-shaded surface", each with a description that explains the mode in slightly more detail. Also note that the primitive color is composed of the material's "Kd" or "Ka" and "d" values. On the downside, several components of the setup just cannot be emulated correctly in this scope because they need other variables, etc. not supported here (ex. Shade comes to mind here, which needs lighting, or the Environment color/alpha, which is set by the game itself if I'm not mistaken). Also, multitexturing doesn't work right yet - neither in the preview, nor (if it was implemented already) in the Display List generator. Several variables for that I still have to gather together, make editable, make the preview use them, then make the eventual DList generator use them. Finally, don't expect more seemingly fast progress like this. I could reuse code from Sayaka here, for example, and there's still a bunch of work to do in this part alone (multitexturing). EDIT: As mentioned shouted on the shoutbox and in the "post what you're doing" thread, finally I managed to replicate some bloody multitexturing in custom maps! There's a bunch of manual hacking around going on still, the textures in question cannot be CI-type textures (limitation of the console? dunno), I had to replace a scene with pre-existing grass (Kakariko for the example) because otherwise Environment Alpha wouldn't be set correctly, but it kinda works! Edited January 19, 2012 by xdaniel Link to comment Share on other sites More sharing options...
xdaniel Posted January 19, 2012 Author Share Posted January 19, 2012 (edited) New original SharpOcarina build v0.6/r17: http://code.google.c...Ocarina-v06.rar Changelog since r15: r16: Trying to get back to SO; finally added triangulation code by marshallh, added check for valid texture image formats in .obj loader, fixed bug that prevented correct manual input of collision polygon type data... r17: Added partial and experimental support for multi-texturing, added option to force texture conversion into 16-bit RGBA textures, updated ReadMe.txt and upped version number in preparation for new build Multi-texturing support is ~2 hours old and rather rudimentary. It works, but setting it up is somewhat difficult and not that user-friendly... I'll see about posting an example or something later. Also, please read the Readme, there's some important information about that. EDIT: Alright, some usage notes on multi-texturing in v0.6. First of all, the important piece of information in the Readme I mentioned, seeing how no one actually reads that anyway: A few more notes about multi-texturing: This feature is pretty experimental and (admittedly) rather badly implemented, perhaps even more so than the rest of the program. In addition, the combiner setup that is currently used for this - the same that ex. the grass in Hyrule Field and other areas uses - depends on proper Environment Alpha being supplied by the game. This has only been verified to be the case when overwriting scene numbers that already had multi-texturing (ex. Kakariko Village, scene number 82). Other scenes, like SharpOcarina's default Sasatest, 108, do not appear to supply the correct data for this. This can -probably- be changed by modifying the scene table, but, at the time of this writing, this hadn't be tested yet. Next up, an example. Multi-texturing is group-based, like pretty much everything else in this regard in SO, so make sure your grass or whatever is a group of its own. Select your group on the "Rooms" tab, then have a look at the two new options at the tab's bottom. "Multitexture Material" is the material that gets added to the base texture, the scaling of which is controlled by the "Shift S/T" options below it. Values of zero are the default, which means that no scaling is applied and ex. two textures of 32x32 pixels are drawn on top of each other in a 1:1 ratio. Setting each value to 1 doubles the virtual size of the overlayed texture, so that it covers four of the underlying textures. I think this image illustrates it well: Here, the "2" is the base texture as seen in SketchUp, SO's preview, etc., while the "1" is the texture overlayed via the N64's color combiner. See how the "1" covers four "2"s? That's what I was trying to say. It also works in the opposite direction, so if you set the "Shift S/T" values to ex. -1, you'll have 4 "1" textures covering a single "2": (Well, technically they aren't drawn on top of each other and rather are being mixed, but I simplified it for the sake of explanation) Also, note that the 3D preview in SO does not actually support multi-texturing. As it's just a simple .obj viewer, it isn't capable of combiner emulation, so you have to mess around a bit and maybe import the map a few times until the settings are right for you. In addition, the whole thing is pretty rudimentary, so there's no fancy material browser (like the rewrite is going to have), which means you need to select the texture to be mixed in by name. Just give your textures descriptive names - unlike my "texture_0x0201AB98_fmt0x10" for example - and it'll be fine. Anything else I wanted to say... I don't think so. Try the feature out, tell me what works (hopefully everything) and what doesn't (hopefully nothing ), basically: make some grass! EDIT 2: Been messing around a bit myself. Texture mapping isn't perfect - probably since I cut up and moved around an already textured surface - but it's something: Edited January 19, 2012 by xdaniel Link to comment Share on other sites More sharing options...
Jabba Posted January 19, 2012 Share Posted January 19, 2012 Freakin awesome! Great work man, never fail to impress. Can't wait to give this a whirl. Link to comment Share on other sites More sharing options...
Jason777 Posted January 20, 2012 Share Posted January 20, 2012 Awesome! I'll be testing this for the next few days Link to comment Share on other sites More sharing options...
haddockd Posted January 20, 2012 Share Posted January 20, 2012 You should start asking for donations for your tools. No harm in it...and it may help give you incentive for projects when it is hard to find it elsewhere... Just an idea. Link to comment Share on other sites More sharing options...
The Tjalian Posted January 20, 2012 Share Posted January 20, 2012 Xdan, I'm not sure if this has been asked before so I apologise if it has, but what are the chances are you releasing the source code of newer versions of SO? I'm really interested in delving into it on an educational basis, to see how tools like this are done. Link to comment Share on other sites More sharing options...
xdaniel Posted January 20, 2012 Author Share Posted January 20, 2012 Xdan, I'm not sure if this has been asked before so I apologise if it has, but what are the chances are you releasing the source code of newer versions of SO? I'm really interested in delving into it on an educational basis, to see how tools like this are done. The rewrite isn't anywhere near working status yet, so that one's source is not coming out until the first actual program release. The original SO' Google Code SVN is constantly being updated, tho... or well, whenever there's something significant that's been done. The most recent source, as used for the v0.6 binary from yesterday, is on the SVN: http://code.google.c.../source/browse/ - to be exact, that was the as-of-now current revision r17. Link to comment Share on other sites More sharing options...
The Tjalian Posted January 21, 2012 Share Posted January 21, 2012 I'm a moron. I saw the solution file not being updated and assumed that the whole projected hadn't been updated since then... >_> thanks haha. Link to comment Share on other sites More sharing options...
Recommended Posts