Register - Login
Views: 99378500
 Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies		 04-23-22 10:18:30 PM
Jul - SM64 Hacking (Archive) - Using Blender New poll - New thread - New reply
Pages: 1 2 3 Next newer thread | Next older thread
Gecko
Member
Level: 25


Posts: 9/113
EXP: 83008
For next: 6612

Since: 03-27-09


Since last post: 9.1 years
Last activity: 7.6 years
Posted on 04-21-09 09:51:59 AM (last edited by Gecko at 07-05-10 01:58 PM) Link | Quote
Update Feb 28th

I've uploaded a basic texturization tutorial showing breegullbeak's level.

Blender - Texturization Tutorial

--------------------
Update May 1st

The third tutorial will be postponed until there's a compatible way of texturization that fully works with the importer.
Until then, I'd suggest you to read the following tutorial: Vertex groups
There are also tutorials dealing with texturization, which you can also read. But, for the video I will try to show you the easiest way and I will also address problematic issues that will appear.

--------------------

Blender is a 3D editor which is completely free and with its ability to export Wavefront .OBJ files predestined for the creation of level geometry for Mario 64.
I've created a tutorial which shows you the basic use of the editor. It will teach you how to create a 3D environment with Blender.

Blender - Preperations for Creating a 3D Environment

Blender - Creating a 3D Environment

Blender - Texturization Tutorial
--------------------

Ressources

I will always release my sources to the public, because I think it will others help understanding how I did certain things.

Finished map - Blender, .obj and material files

--------------------

In the next step I will create a video showing you how to utilize those tools for the creation of a level.
I have created this tutorial, because I saw Bob Omb and RDX writing that they were having problems using Blender. I'm still a beginner by myself, but I can assure you that I haven't been using this editor for more an 2 hours and by now I'm somewhat able to create a 3D environment.

--------------------

How to flip normals:



Only the top side of a plane gets drawn, which means that after assigning a material/texture to it, you'll see the texture on the top side. When you're looking on bottom side of the plane, it's invisible. If both sides of a plane would be drawn, the engine would also use twice as many ressources. Usually, you will never see the bottom side of a plane, because it would mean that you have to leave the map and fly to the bottom side of the level. However, you may have seen level geometry from it's back side becoming invisible to you.

Here's a top and bottom view of the level:


When extruding edges and creating new faces, Blender sometimes does not know which side is supposed to be the top and simply flips it over onto the wrong side resulting in it becoming invisible. In order to fix this issue, you have to flip normals, which is shown in the picture above.

Additionally, point 4 shows you how to change what you will select by right clicking. In the tutorial I always selected single vertices. Using these buttons will allow you to select edges or complete faces.

Point 2 shows you how to change model view: Textured mode (hotkey is ALT+Z), shaded mode, solid mode (Hotkey Z) or wireframe mode (Hotkey also Z).

At point 1 you're able to go into "Material mode" which allows you to assign textures.

--------------------

Mario often fell through the ground around the tree bark which is covered by that rose texture at first or there were invisible walls which made it possible for Mario to pass through even though there were no obstacles.
I started rebuilding that ground after having deleted all faces and even could save some polygons and it worked afterwards. Mario did not push against invisible walls anymore. It could be that the engine has problems with planar grounds consisting of more polygons than actually needed like in the upper part of the picture. At the botton there are no unneeded faces anymore.


--------------------

Something else bugging me was when Mario fell through the ground at some points. That always was due to the level geometry. I could trick the engine by extruding all those foul faces and put them minimally above their surrounding ground:
1. Select foul faces or the whole connected ground (edit mode - face selection - right click on faces holding shift)
2. Press E for extrusion
3. Press e.g. 0.01 (zero point zero one or any other minimal value)
4. Press Enter
The polygon count becomes bigger, but the buggy grounds vanished, at least for those I tried.
It would be nice if someone checked and veryfied/falsified this.

--------------------

Next thing was disappearing objects and water after having added objects to the game in TT64.

I excluded object by object and found out that the Bullet Bill cannon was responsible for this. After deleting them everything worked fine again.
Hectamatatortron
Member
Level: 35


Posts: 142/232
EXP: 257990
For next: 21946

Since: 09-19-07


Since last post: 7.2 years
Last activity: 5.3 years
Posted on 04-21-09 02:48:27 PM Link | Quote
Neat.

I was going to use this program (and its built in physics engine, "Bullet") to help me get started messing around with 3D programming for the Nintendo DS.

Also, if you don't like the drawing system for Blender (I haven't tried it yet), you can get Google Sketch Up for free, draw in there (seemed intuitive enough when I tried it) and export the vertex data, after which you can probably import it into Blender easily enough.

Anyway, is that polygon importer done or something? Or is there some other way to put the output of Blender into the game?

I've mostly just been lurking in this section of the forum because messiaen's efforts are hard to ignore.

____________________
Gecko
Member
Level: 25


Posts: 10/113
EXP: 83008
For next: 6612

Since: 03-27-09


Since last post: 9.1 years
Last activity: 7.6 years
Posted on 04-22-09 08:26:30 AM Link | Quote
Thanks!

It's not possible to import level geometry, yet, but until VL-Tone ironed out the last bugs we can get things going and start creating levels or actually start to learn how to use 3D editors, which is the reason why I have created this tutorial.
This forum is a great place for exchanging ideas and knowledge and I'm happy that there are other beginners who start to get into 3D modeling, like me. I'd be really happy if I could help others to understand how to use Blender, even though I'm just beginning to understand the usage of the editor by myself.

I've tried to work with Google Sketch Up and even after watching some tutorials I unfortunately could not grasp how to use the program, even though it looked kind of intuitive. I wonder if it was laid out for the creation of 3D game environments due to its main purpose being creating models of buildings for Google Earth, unless I'm not mistaken.

For the next tutorial, it would be great if you could give me some advice on what I should model for you. Of course, it should not be too complicated and keep in mind that it should fit into Mario 64.
RDX

Level: 32


Posts: 60/198
EXP: 193359
For next: 13083

Since: 02-14-09


Since last post: 10.8 years
Last activity: 10.5 years
Posted on 04-25-09 04:49:49 PM (last edited by RDX at 04-26-09 02:43 PM) Link | Quote
Oh woops, looks like I was using a different tutorial

If you have the time to put aside (Basically an entire day and a bit), then I'd recommend reading this:
http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro

____________________
Hectamatatortron
Member
Level: 35


Posts: 149/232
EXP: 257990
For next: 21946

Since: 09-19-07


Since last post: 7.2 years
Last activity: 5.3 years
Posted on 04-25-09 06:48:46 PM Link | Quote
I'm a beginner to 3D drawing, but I'm definitely not a beginner.

I got Blender before I saw this thread because it uses the Bullet engine that I was going to learn the API of for a homebrew game I started.

I decided to do most of the game in Blender and get it running on the PC before trying to port it to the DS and then to the Wii. I learned enough about OpenGL to be confident in my ability to import objects I draw in Blender into homebrew applications in the future.

So far I've only drawn a bullet object (not because of the humorous pun, but because I'm working on a first person shooter) and practiced enabling movement of the camera "in game" (when the game engine of Blender is active) by assigning movement directions to arrow keys (though the interface suggests the relationship is the other way around).

I just wish there was a tool for indenting surfaces using a sort of spherical shaped tool to "push" faces inward, automatically splitting the face into sub-faces as necessary. That would make 3D drawing much easier. Isn't that what the better apps do?

But hey, Google's Sketch Up might do the trick. I'm sure it's easy enough to export from Sketch Up and import into Blender.

If you need me to write any applications to convert formats, just give me the specifics of the source and destination formats and I can write something up. What exactly is VL-Tone having trouble with? Seems like he can import polygons, just not textures? We should prototype the insertion process by using a bland default texture for imported 3D models to at least test that the vertex importing functionality works.

____________________
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 449/621
EXP: 1135500
For next: 21619

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 1.2 years
Posted on 04-26-09 02:29:52 AM Link | Quote
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by Hectamatatortron
I'm a beginner to 3D drawing, but I'm definitely not a beginner.

I got Blender before I saw this thread because it uses the Bullet engine that I was going to learn the API of for a homebrew game I started.

I decided to do most of the game in Blender and get it running on the PC before trying to port it to the DS and then to the Wii. I learned enough about OpenGL to be confident in my ability to import objects I draw in Blender into homebrew applications in the future.

So far I've only drawn a bullet object (not because of the humorous pun, but because I'm working on a first person shooter) and practiced enabling movement of the camera "in game" (when the game engine of Blender is active) by assigning movement directions to arrow keys (though the interface suggests the relationship is the other way around).

I just wish there was a tool for indenting surfaces using a sort of spherical shaped tool to "push" faces inward, automatically splitting the face into sub-faces as necessary. That would make 3D drawing much easier. Isn't that what the better apps do?

But hey, Google's Sketch Up might do the trick. I'm sure it's easy enough to export from Sketch Up and import into Blender.

If you need me to write any applications to convert formats, just give me the specifics of the source and destination formats and I can write something up. What exactly is VL-Tone having trouble with? Seems like he can import polygons, just not textures? We should prototype the insertion process by using a bland default texture for imported 3D models to at least test that the vertex importing functionality works.


The vertex functionality works, I already created a demo level with it.

I don't have any problems reading the .obj and .mtl files, except for the texture file paths in the .mtl file, found after the map_Kd command.

There's some lack of standards regarding the kind of path that should be there. Some programs will output an absolute path, some don't. And for a relative path, some will use ".\\" at the begining of the path name, some will not. There's also the potential issue of some program using UNIX style path (slashes instead of backslashes). Some programs put the textures in a different folder even though they are referenced by a simple relative path that doesn't include the name of the texture folder (essentially just the texture file name). These will open fine with Blender because it does a recursive search to find them.

I guess it's just laziness on my part, but I didn't want to deal with that mess.

That being said, I'm reconsidering the possibility of importing textures directly using the .mtl file. What I'll do is simply extract the filename from the path (if it's absolute) and try to open the texture file in the same folder as the .mtl file. I may also add support for a texture folder, which may be called "Materials", but this name will be hard-coded. TT64 will first try to open it in the same path as the .mtl file, then try the "Materials" folder. If it fails there won't be any recursive search. Director doesn't have built-in commands to achieve it, and it would require yet another plug-in, which may or may not be free.

This will force users to make sure that their textures are in the same folder or in a folder called "Materials".

____________________
Gecko
Member
Level: 25


Posts: 23/113
EXP: 83008
For next: 6612

Since: 03-27-09


Since last post: 9.1 years
Last activity: 7.6 years
Posted on 04-26-09 10:04:09 AM (last edited by Gecko at 04-26-09 09:23 AM) Link | Quote
Originally posted by VL-Tone

That being said, I'm reconsidering the possibility of importing textures directly using the .mtl file. What I'll do is simply extract the filename from the path (if it's absolute) and try to open the texture file in the same folder as the .mtl file. I may also add support for a texture folder, which may be called "Materials", but this name will be hard-coded. TT64 will first try to open it in the same path as the .mtl file, then try the "Materials" folder. If it fails there won't be any recursive search. Director doesn't have built-in commands to achieve it, and it would require yet another plug-in, which may or may not be free.

This will force users to make sure that their textures are in the same folder or in a folder called "Materials".


One additional way of importing obj files I thought of, after having read some posting from you about the obj importer, was using the mtl file just as indicator that there are vertex groups with materials making TT ask you which texture from the ROM file to assign to these vertex groups with the option of loading new texture files into the ROM.


or:
Me-me
340
Level: 41


Posts: 75/341
EXP: 461678
For next: 18467

Since: 08-05-07


Since last post: 9.7 years
Last activity: 8.1 years
Posted on 04-26-09 10:20:52 AM Link | Quote
I don't know how to assign textures to the models I create.
So anyone who knows how, please tell me. Thank you very much.

____________________
Wow! SM64 is totally turned upside-down!
Gecko
Member
Level: 25


Posts: 25/113
EXP: 83008
For next: 6612

Since: 03-27-09


Since last post: 9.1 years
Last activity: 7.6 years
Posted on 04-26-09 10:26:41 AM Link | Quote
Give me a little time and I will try to make a tutorial.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 454/621
EXP: 1135500
For next: 21619

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 1.2 years
Posted on 04-26-09 08:33:59 PM Link | Quote
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Gecko, the second screenshot is exactly the kind of interface I was planning to build. And a similar interface will be needed anyway since there are some additional parameters to be set for each texture even when they're automatically imported using the .mtl file. "Use transparency" for example, and other parameters that may be added in the future that are particular to the SM64 engine and are not easily transferable using the .obj file format.

The main difference though, is that to stay consistent with the way the importer works, texture will be managed inside the level file not inside the ROM, since the former which contains everything needed to create your levels. The textures are only saved to the ROM when you save your level there, with the rest of the data.

So instead of "Select texture from ROM" and "Load new texture into ROM", I'll put an "Import Texture" and "Export Texture" that will import/export textures from external bitmap files.

Here's how it will work:

-You open the ROM in TT64.
-Go to the level importer.
-Create a new level file (or open an existing one)
-Import an .obj file.
-Materials are listed.
-If the importer can find the texture files using the .mtl, those are imported and automatically associated with the Material groups.
-If the importer cannot find the external textures using the .mtl, blank/default textures will be used.
-You can then manually import textures into materials whether the textures where already imported or not.
-Save the level file.
-Save the level to ROM.

Now... it all seems easy until this problem arises:

The .obj data, all the importing parameters (scale, offset, banks etc.) and the texture themselves as well as their names are all saved into the .T64 level file.

The idea is that this file can be used to recreate the level inside another ROM, or if you want to update the .obj data for a given, you don't have to set all the import parameters all over again.

But let's say you open a level file where you manually imported textures. Once you open it, everything will be fine, the textures will be automatically associated with the materials etc. But what if you want to update the .obj data? You can hit the "Import .obj" button and do that....but the default behavior will be to completely replace the current textures and materials with those found using the .obj and .mtl files, so you lose your custom textures and will have to reimport/associate each of them again.

I guess I can make a "keep existing textures" checkbox so that when you import an updated .obj you can keep those that were originally in the level file. But what if either the material or texture names have changed since the last import? TT64 won't be able to associate these textures and they'll become inaccessible via the interface.

Anyway, I'm not saying it's impossible to deal with these problems, but it certainly makes it more complicated.

____________________
Gecko
Member
Level: 25


Posts: 26/113
EXP: 83008
For next: 6612

Since: 03-27-09


Since last post: 9.1 years
Last activity: 7.6 years
Posted on 04-27-09 07:38:13 PM (last edited by Gecko at 04-27-09 04:42 PM) Link | Quote
Originally posted by VL-Tone
Gecko, the second screenshot is exactly the kind of interface I was planning to build. And a similar interface will be needed anyway since there are some additional parameters to be set for each texture even when they're automatically imported using the .mtl file. "Use transparency" for example, and other parameters that may be added in the future that are particular to the SM64 engine and are not easily transferable using the .obj file format.

The test maps from Mario 64 DS (video link) give a good overview on the texture attributes and ground types. The player reaches these at about 1:30 in the video where you will see those kanji on the ground.
Are these attributes already connected to the existing textures in the game or do these always have to be applied anew when assigning textures in a newly imported level?
The first point would be the easier way, because that would mean once one's importing a new texture he could be asked which attribute to apply to the texture instead of having to change attributes whenever he's applying a texture to a vertex/material group when importing a new .obj file.

Originally posted by VL-Tone

The main difference though, is that to stay consistent with the way the importer works, texture will be managed inside the level file not inside the ROM, since the former which contains everything needed to create your levels. The textures are only saved to the ROM when you save your level there, with the rest of the data.

With regard to your container based level file system (.T64 level file), that will be the best option. Will you be able to extract all files from your level container once it has been created (extracting .obj and material files and so on)?

Assuming that I'd like to load a level from the ROM without having any of its original data, because that level was created by someone else, for instance, will it be possible to create a container from a ROM level file by which I mean reversing the whole process? If that reversed process would mean too much programming, maybe it could be useful having a copy of the container (.T64 level file) inside the ROM making it possible to extract it easily if intended.

Originally posted by VL-Tone

So instead of "Select texture from ROM" and "Load new texture into ROM", I'll put an "Import Texture" and "Export Texture" that will import/export textures from external bitmap files.

Here's how it will work:

-You open the ROM in TT64.
-Go to the level importer.
-Create a new level file (or open an existing one)
-Import an .obj file.
-Materials are listed.
-If the importer can find the texture files using the .mtl, those are imported and automatically associated with the Material groups.
-If the importer cannot find the external textures using the .mtl, blank/default textures will be used.
-You can then manually import textures into materials whether the textures where already imported or not.
-Save the level file.
-Save the level to ROM.

Now... it all seems easy until this problem arises:

The .obj data, all the importing parameters (scale, offset, banks etc.) and the texture themselves as well as their names are all saved into the .T64 level file.

The idea is that this file can be used to recreate the level inside another ROM, or if you want to update the .obj data for a given, you don't have to set all the import parameters all over again.

But let's say you open a level file where you manually imported textures. Once you open it, everything will be fine, the textures will be automatically associated with the materials etc. But what if you want to update the .obj data? You can hit the "Import .obj" button and do that....but the default behavior will be to completely replace the current textures and materials with those found using the .obj and .mtl files, so you lose your custom textures and will have to reimport/associate each of them again.

I guess I can make a "keep existing textures" checkbox so that when you import an updated .obj you can keep those that were originally in the level file. But what if either the material or texture names have changed since the last import? TT64 won't be able to associate these textures and they'll become inaccessible via the interface.

Anyway, I'm not saying it's impossible to deal with these problems, but it certainly makes it more complicated.

Reassociating textures to a vertex/material group from the .obj file will not be too much work since there will be just as few as maybe 15 textures inside a level.
I think that attributes, scale and so forth could be connected to the texture which will finally be associated from the ROM. As soon as you are assigning that texture to a vertex/material group again, its attributes will be applied.

1. import obj
2. assign "grass" texture to "material group 2"
3. scale, rotate it... for instance there will be the following values: "scale 3", "rotate 167"...
4. save .T64 level file.

Now these attributes "scale 3" and "rotate 167" will be connected to the "grass" texture inside the .T64 level file.

5. open .T64 level file
6. import an updated obj overwriting the old one - now all materials will have to be reassigned
7. assign "grass" texture to "material group 5"
8. user will be asked to apply existing attributes

As soon as the "grass" texture would be assigned to more than one material group, both attributes would have to be saved into the .T64 level file. When the user updates the object file and applies the "grass" texture onto a material group he will be asked if he wants to adopt the first or second (or third or fourth...) attribute data with the possibility of previewing each settings.

This will only make sense as long as there will not be 130 material groups of which 25 would be assigned the "grass" texture.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 461/621
EXP: 1135500
For next: 21619

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 1.2 years
Posted on 04-29-09 04:18:14 AM Link | Quote
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by Gecko

The test maps from Mario 64 DS (video link) give a good overview on the texture attributes and ground types. The player reaches these at about 1:30 in the video where you will see those kanji on the ground.
Are these attributes already connected to the existing textures in the game or do these always have to be applied anew when assigning textures in a newly imported level?
The first point would be the easier way, because that would mean once one's importing a new texture he could be asked which attribute to apply to the texture instead of having to change attributes whenever he's applying a texture to a vertex/material group when importing a new .obj file.


In the SM64 engine, terrain attributes are defined by the collision map, they're completely independent on texture and materials.

It was originally planned for 0.6 that you'd be able to set the terrain attribute for the whole level (Shown in the interface as "Collision Terrain Type"). In version 0.7, I wanted to allow setting the terrain attributes for vertex groups and even individual polygons.

But with the new direction 0.6 is taking, I think it would make more sense to set terrain attributes for materials instead of groups. That would make it so much simpler for the users. And if you really want two areas that have the same texture but two different terrain attribute, you could always create two materials with a different name and a different file name for the texture, even though the actual bitmap would be the same.
Originally posted by Gecko

With regard to your container based level file system (.T64 level file), that will be the best option. Will you be able to extract all files from your level container once it has been created (extracting .obj and material files and so on)?


It was not planned, but it's a good idea , I'll probably implement it, though it may be in 0.6.1 or another future version.
Originally posted by Gecko

Assuming that I'd like to load a level from the ROM without having any of its original data, because that level was created by someone else, for instance, will it be possible to create a container from a ROM level file by which I mean reversing the whole process? If that reversed process would mean too much programming, maybe it could be useful having a copy of the container (.T64 level file) inside the ROM making it possible to extract it easily if intended.


Well it wouldn't be simple to reverse the process.

Also, you shouldn't use a level from someone else without having his permission, and if you have to ask, you might as well ask for the original .T64 file. Mod creators could also bundle their .T64 (and .obj files) with the ROM patch if they choose so.

The limitation is not there because of these reasons, I didn't willingly implement some kind of copy protection, but I think that in "normal" situations, not having the ability to extract a .T64 from the ROM won't cause any major problems.

As for including a copy of the .T64 file in the ROM, it would end up taking too much space.
Originally posted by Gecko

Reassociating textures to a vertex/material group from the .obj file will not be too much work since there will be just as few as maybe 15 textures inside a level.
I think that attributes, scale and so forth could be connected to the texture which will finally be associated from the ROM. As soon as you are assigning that texture to a vertex/material group again, its attributes will be applied.

1. import obj
2. assign "grass" texture to "material group 2"
3. scale, rotate it... for instance there will be the following values: "scale 3", "rotate 167"...
4. save .T64 level file.

Now these attributes "scale 3" and "rotate 167" will be connected to the "grass" texture inside the .T64 level file.

5. open .T64 level file
6. import an updated obj overwriting the old one - now all materials will have to be reassigned
7. assign "grass" texture to "material group 5"
8. user will be asked to apply existing attributes

As soon as the "grass" texture would be assigned to more than one material group, both attributes would have to be saved into the .T64 level file. When the user updates the object file and applies the "grass" texture onto a material group he will be asked if he wants to adopt the first or second (or third or fourth...) attribute data with the possibility of previewing each settings.

This will only make sense as long as there will not be 130 material groups of which 25 would be assigned the "grass" texture.


This is getting too complicated. I'll have to think about it like tomorrow, I'm getting tired and can't wrap my brain around a simple solution...

____________________
Gecko
Member
Level: 25


Posts: 29/113
EXP: 83008
For next: 6612

Since: 03-27-09


Since last post: 9.1 years
Last activity: 7.6 years
Posted on 04-29-09 03:25:49 PM Link | Quote
Maybe it would be easier having TT extract all textures from the ROM saving them numerized (first texture is named 001.png and so on) inside "ToadsTool/Materials" folder allowing to use these for the creation of levels.

While creating a level with an editor (e.g. Blender), the user would take all materials out of the "ToadsTool/Materials" folder.

When TT then imports .obj and .mtl file, it would not matter if the .mtl file included absolute or relative paths, because TT would just import the image files from the "ToadsTool/Materials" folder.



I will just leave the main idea the way it is in order not to make it too complicated until you think it would be realizable.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 462/621
EXP: 1135500
For next: 21619

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 1.2 years
Posted on 04-29-09 07:48:06 PM (last edited by VL-Tone at 04-29-09 04:48 PM) Link | Quote
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by Gecko
Maybe it would be easier having TT extract all textures from the ROM saving them numerized (first texture is named 001.png and so on) inside "ToadsTool/Materials" folder allowing to use these for the creation of levels.

While creating a level with an editor (e.g. Blender), the user would take all materials out of the "ToadsTool/Materials" folder.

When TT then imports .obj and .mtl file, it would not matter if the .mtl file included absolute or relative paths, because TT would just import the image files from the "ToadsTool/Materials" folder.



I will just leave the main idea the way it is in order not to make it too complicated until you think it would be realizable.


TT64 already includes a feature to save all textures into a folder. I don't think I'll integrate this process into the importer.

Before anything else, I want the thing to be able to import textures directly using the obj/mtl file. The only requirement will be to put the texture files at the same directory level as the .obj file. Absolute/relative paths won't matter, since I'll only extract the file names from the .mtl file, not the rest of the path.

Being able to manually import textures will only be a bonus feature, I will encourage people to manage textures in Blender or their favorite 3d program instead.

For now I'll focus on making the basic functionality actually work. The actual .obj importer code still wasn't ready to use the new multi-level feature, nor multi-texture models. Last night I managed to make it work for the first time, using your model as an example, though there are still some bugs, like texture coordinates being messed up (even though they're now perfectly fine in the 3d preview). I'll post some screenshots and probably some video when I resolve these issues.

Something I discovered while testing your model in the game, and it was something I already thought would happen, is that the SM64 collision engine is pretty buggy, there were a few places in your level where Mario simply fell through the ground. I'm sure that the original levels were tested again and again to get rid of these kind of issues (even modern games are throughly tested for holes/problems in the collision map).

____________________
Gecko
Member
Level: 25


Posts: 30/113
EXP: 83008
For next: 6612

Since: 03-27-09


Since last post: 9.1 years
Last activity: 7.6 years
Posted on 04-29-09 08:42:49 PM Link | Quote
Originally posted by VL-Tone
Something I discovered while testing your model in the game, and it was something I already thought would happen, is that the SM64 collision engine is pretty buggy, there were a few places in your level where Mario simply fell through the ground. I'm sure that the original levels were tested again and again to get rid of these kind of issues (even modern games are throughly tested for holes/problems in the collision map).

Maybe flattening problematic triangles could help reducing the glitches. In the original game there mostly are flat surfaces unlike in my level which is pretty hilly.

At least it's nice to see that even inside the normal game this glitch still exists.
Fall through ground
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 463/621
EXP: 1135500
For next: 21619

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 1.2 years
Posted on 04-30-09 05:34:28 AM Link | Quote
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Ok I've fixed most of the texture problems I had with in-game textures. Turn out that your texture coordinates included negative numbers, and the SM64 drawing engine requires positive numbers. A temporary fix was to find the lowest negative value, then substract it from all texture coordinates so that their minimum is zero.

It fixed every texture problems except one, that you can see in this screenshot:




It only affects the brown texture found on the side of the hills. While those display perfectly in the TT64 3d preview, they do that in the game...

One thing to note is that while Blender and the .OBJ format provide U,V texture coordinates, the N64 engine uses S,T coordinates. I have a hard time finding on the web any clear explanation of the difference between the two formats and a straightforward way to convert between the two systems. I managed to convert the S,T coordinates into U,V coordinate in TT64 to display levels and models in the editor, but it was by trial and error and I'm still not sure how I've done it (it's some very early code in TT64 that I haven't touched since it worked).

I've found some pages that seem to say that UV and ST coordinates are the same thing, while other seemed to say that converting between them was a complicated process.

Anyway it seems that a direct use of UV coordinates works for all textures in your model except the brown one. Did you do anything special to that texture in particular (some kind of special scaling maybe?). Maybe it has something to do with the unwrapping process, as those particular polygons are mostly vertical, and they're unwrapped differently (flat on their side) in a way that makes them incompatible with S,T coordinates?

____________________
Gecko
Member
Level: 25


Posts: 31/113
EXP: 83008
For next: 6612

Since: 03-27-09


Since last post: 9.1 years
Last activity: 7.6 years
Posted on 04-30-09 06:39:13 AM (last edited by Gecko at 04-30-09 04:09 AM) Link | Quote
At first, I've selected all faces at once making them the first vertex group with one texture in order not to leave face unselected/untextures. Afterwards, I've created other vertex and material groups and assigned e.g. the ground to it. Those walls are the leftovers of the first vertex/material group.

I've quickly unwrapped the walls again: http://depositfiles.com/files/1z9utm5fn
If that does not work, I will have to think about something different.

Something that quickly came to my mind was how textures are projected onto angular faces, maybe there's a switch like in the Half-Life engine.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 464/621
EXP: 1135500
For next: 21619

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 1.2 years
Posted on 04-30-09 07:18:24 AM (last edited by VL-Tone at 04-30-09 04:20 AM) Link | Quote
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Well that didn't work, the textures are as messed up on the sides, and now a few triangles on the other textures on the floor as messed up too

Maybe we could try with a very basic shape like a textured cube, so I can try to debug the thing manually. It may well be a bug in my code, or maybe observing the data up close will enable me to find how to convert the UV textures correctly. For now there are too many polygons for me to pin-point where the problem is.

____________________
Gecko
Member
Level: 25


Posts: 32/113
EXP: 83008
For next: 6612

Since: 03-27-09


Since last post: 9.1 years
Last activity: 7.6 years
Posted on 04-30-09 07:35:07 AM (last edited by Gecko at 04-30-09 11:38 AM) Link | Quote
Ok, here's the cube and I've unwrapped the vertex group again, but didn't scale the texture.
http://depositfiles.com/files/evsej0h46

Blender actually outputs negative scales depending on the scale movement. Moving the mouse left makes the scale negative and vice versa.

Edit: Taken from link
Basically if your st coordinates map linearly
to the xyz vertices, then breaking the poly into triangles to scan convert
will produce consistent and correct results. However, if your st coordinates
map non-linearly, then tessellating into triangles will produce different
results depending on screen orientation of the geometry.

Maybe the .obj export produces some errors. I've tried to other export options of which the first leaves triangulation off (the map already has all quads converted to triangles making the triangulation option probably redundant) and the second file output uses the HQ normals option.

http://depositfiles.com/files/ypo8potg1

I've created a new vertex group/uv map for the skyscraper's walls and every UV map now is redone:
http://depositfiles.com/files/r3hq4bq2h
All other export options are as usual.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 466/621
EXP: 1135500
For next: 21619

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 1.2 years
Posted on 05-01-09 06:21:06 AM (last edited by VL-Tone at 05-01-09 03:21 AM) Link | Quote
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Ok forget about the S,T/U,V translation problem, that had nothing to do with it.

There was something definitely screwy on TT64's side. Because of a mistake, the N64 polygon command encoder was using ridiculously large texture coordinates numbers (in the range of 50,000) but somehow it worked for some range of values like the ones used in floor polygons.

Here's the result with the bug fix:



This is with multiplying the provided texture coordinates by 50. Using a lower number will result in lower texture density, and using an higher number results in higher density, except that going over about 50, some texture on the sides begin to get screwed much like they were with the other bug.

It seems to have to do with the fact that these texture repeat much more in a single polygon than the floor textures, maybe it's a limitation of the N64 drawing engine, and that there's a maximum number of times a texture can get repeated on a given polygon. Or maybe again it's a bug in TT64.

____________________
Pages: 1 2 3 Next newer thread | Next older thread
Jul - SM64 Hacking (Archive) - Using Blender New poll - New thread - New reply


Rusted Logic
Acmlmboard - commit 47be4dc [2021-08-23]
©2000-2022 Acmlm, Xkeeper, Kaito Sinclaire, et al.

30 database queries, 15 query cache hits.
Query execution time:  0.093417 seconds
Script execution time:  0.075555 seconds
Total render time:  0.168972 seconds


TidyHTML vomit below
line 1 column 1 - Warning: missing <!DOCTYPE> declaration
line 2 column 300 - Warning: unescaped & or unknown entity "&page"
line 119 column 11 - Warning: <form> isn't allowed in <table> elements
line 118 column 10 - Info: <table> previously mentioned
line 120 column 11 - Warning: missing <tr>
line 120 column 119 - Warning: missing </font> before </td>
line 124 column 16 - Warning: plain text isn't allowed in <tr> elements
line 120 column 11 - Info: <tr> previously mentioned
line 125 column 68 - Warning: missing </nobr> before </td>
line 141 column 68 - Warning: missing </nobr> before <tr>
line 147 column 35 - Warning: missing <tr>
line 147 column 50 - Warning: missing </font> before </td>
line 148 column 37 - Warning: unescaped & or unknown entity "&id"
line 147 column 184 - Warning: missing </font> before </table>
line 149 column 35 - Warning: missing <tr>
line 149 column 96 - Warning: unescaped & or unknown entity "&page"
line 149 column 128 - Warning: unescaped & or unknown entity "&page"
line 149 column 50 - Warning: missing </font> before </td>
line 149 column 163 - Warning: missing </font> before </table>
line 156 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 158 column 9 - Warning: missing <tr>
line 176 column 13 - Warning: missing <tr>
line 177 column 101 - Warning: unescaped & or unknown entity "&postid"
line 183 column 230 - Warning: unescaped & or unknown entity "&fmt"
line 201 column 1502 - Warning: unescaped & or unknown entity "&fmt"
line 257 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 259 column 9 - Warning: missing <tr>
line 277 column 13 - Warning: missing <tr>
line 278 column 101 - Warning: unescaped & or unknown entity "&postid"
line 291 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 293 column 9 - Warning: missing <tr>
line 311 column 13 - Warning: missing <tr>
line 312 column 101 - Warning: unescaped & or unknown entity "&postid"
line 324 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 326 column 9 - Warning: missing <tr>
line 344 column 13 - Warning: missing <tr>
line 345 column 101 - Warning: unescaped & or unknown entity "&postid"
line 353 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 355 column 9 - Warning: missing <tr>
line 373 column 13 - Warning: missing <tr>
line 374 column 101 - Warning: unescaped & or unknown entity "&postid"
line 391 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 393 column 9 - Warning: missing <tr>
line 411 column 13 - Warning: missing <tr>
line 412 column 101 - Warning: unescaped & or unknown entity "&postid"
line 414 column 74 - Warning: <style> isn't allowed in <td> elements
line 414 column 9 - Info: <td> previously mentioned
line 414 column 1512 - Warning: missing </font> before <blockquote>
line 414 column 1591 - Warning: inserting implicit <font>
line 414 column 1591 - Warning: missing </font> before <hr>
line 414 column 1664 - Warning: inserting implicit <font>
line 414 column 1664 - Warning: missing </font> before <hr>
line 427 column 1 - Warning: inserting implicit <font>
line 414 column 138 - Warning: missing </div>
line 441 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 443 column 9 - Warning: missing <tr>
line 461 column 13 - Warning: missing <tr>
line 462 column 101 - Warning: unescaped & or unknown entity "&postid"
line 476 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 478 column 9 - Warning: missing <tr>
line 496 column 13 - Warning: missing <tr>
line 497 column 101 - Warning: unescaped & or unknown entity "&postid"
line 503 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 505 column 9 - Warning: missing <tr>
line 523 column 13 - Warning: missing <tr>
line 524 column 101 - Warning: unescaped & or unknown entity "&postid"
line 529 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 531 column 9 - Warning: missing <tr>
line 549 column 13 - Warning: missing <tr>
line 550 column 101 - Warning: unescaped & or unknown entity "&postid"
line 552 column 74 - Warning: <style> isn't allowed in <td> elements
line 552 column 9 - Info: <td> previously mentioned
line 552 column 138 - Warning: missing </div>
line 584 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 586 column 9 - Warning: missing <tr>
line 604 column 13 - Warning: missing <tr>
line 605 column 101 - Warning: unescaped & or unknown entity "&postid"
line 666 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 668 column 9 - Warning: missing <tr>
line 686 column 13 - Warning: missing <tr>
line 687 column 101 - Warning: unescaped & or unknown entity "&postid"
line 689 column 74 - Warning: <style> isn't allowed in <td> elements
line 689 column 9 - Info: <td> previously mentioned
line 689 column 1512 - Warning: missing </font> before <blockquote>
line 689 column 1591 - Warning: inserting implicit <font>
line 689 column 1591 - Warning: missing </font> before <hr>
line 690 column 1 - Warning: inserting implicit <font>
line 690 column 1 - Warning: missing </font> before <hr>
line 693 column 2446 - Warning: inserting implicit <font>
line 694 column 1 - Warning: inserting implicit <font>
line 694 column 1 - Warning: missing </font> before <blockquote>
line 701 column 3333 - Warning: inserting implicit <font>
line 701 column 3333 - Warning: missing </font> before <hr>
line 702 column 1 - Warning: inserting implicit <font>
line 702 column 1 - Warning: missing </font> before <hr>
line 703 column 1 - Warning: inserting implicit <font>
line 703 column 1 - Warning: missing </font> before <blockquote>
line 707 column 3810 - Warning: inserting implicit <font>
line 707 column 3810 - Warning: missing </font> before <hr>
line 708 column 1 - Warning: inserting implicit <font>
line 708 column 1 - Warning: missing </font> before <hr>
line 709 column 1 - Warning: inserting implicit <font>
line 709 column 1 - Warning: missing </font> before <blockquote>
line 718 column 5041 - Warning: inserting implicit <font>
line 718 column 5041 - Warning: missing </font> before <hr>
line 719 column 1 - Warning: inserting implicit <font>
line 719 column 1 - Warning: missing </font> before <hr>
line 737 column 1 - Warning: inserting implicit <font>
line 689 column 138 - Warning: missing </div>
line 741 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 743 column 9 - Warning: missing <tr>
line 761 column 13 - Warning: missing <tr>
line 762 column 101 - Warning: unescaped & or unknown entity "&postid"
line 775 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 777 column 9 - Warning: missing <tr>
line 795 column 13 - Warning: missing <tr>
line 796 column 101 - Warning: unescaped & or unknown entity "&postid"
line 798 column 74 - Warning: <style> isn't allowed in <td> elements
line 798 column 9 - Info: <td> previously mentioned
line 798 column 1512 - Warning: missing </font> before <blockquote>
line 798 column 1591 - Warning: inserting implicit <font>
line 798 column 1591 - Warning: missing </font> before <hr>
line 798 column 1653 - Warning: inserting implicit <font>
line 798 column 1653 - Warning: missing </font> before <hr>
line 807 column 1 - Warning: inserting implicit <font>
line 798 column 138 - Warning: missing </div>
line 819 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 821 column 9 - Warning: missing <tr>
line 839 column 13 - Warning: missing <tr>
line 840 column 101 - Warning: unescaped & or unknown entity "&postid"
line 849 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 851 column 9 - Warning: missing <tr>
line 869 column 13 - Warning: missing <tr>
line 870 column 101 - Warning: unescaped & or unknown entity "&postid"
line 872 column 74 - Warning: <style> isn't allowed in <td> elements
line 872 column 9 - Info: <td> previously mentioned
line 872 column 138 - Warning: missing </div>
line 888 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 890 column 9 - Warning: missing <tr>
line 908 column 13 - Warning: missing <tr>
line 909 column 101 - Warning: unescaped & or unknown entity "&postid"
line 921 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 923 column 9 - Warning: missing <tr>
line 941 column 13 - Warning: missing <tr>
line 942 column 101 - Warning: unescaped & or unknown entity "&postid"
line 944 column 74 - Warning: <style> isn't allowed in <td> elements
line 944 column 9 - Info: <td> previously mentioned
line 944 column 138 - Warning: missing </div>
line 949 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 951 column 9 - Warning: missing <tr>
line 969 column 13 - Warning: missing <tr>
line 970 column 101 - Warning: unescaped & or unknown entity "&postid"
line 977 column 573 - Warning: unescaped & or unknown entity "&cd"
line 977 column 578 - Warning: unescaped & or unknown entity "&hl"
line 977 column 584 - Warning: unescaped & or unknown entity "&ct"
line 977 column 592 - Warning: unescaped & or unknown entity "&gl"
line 977 column 598 - Warning: unescaped & or unknown entity "&client"
line 992 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 994 column 9 - Warning: missing <tr>
line 1012 column 13 - Warning: missing <tr>
line 1013 column 101 - Warning: unescaped & or unknown entity "&postid"
line 1015 column 74 - Warning: <style> isn't allowed in <td> elements
line 1015 column 9 - Info: <td> previously mentioned
line 1015 column 138 - Warning: missing </div>
line 1028 column 17 - Warning: missing <tr>
line 1028 column 17 - Warning: discarding unexpected <table>
line 1031 column 35 - Warning: missing <tr>
line 1031 column 96 - Warning: unescaped & or unknown entity "&page"
line 1031 column 128 - Warning: unescaped & or unknown entity "&page"
line 1031 column 50 - Warning: missing </font> before </td>
line 1031 column 163 - Warning: missing </font> before </table>
line 1033 column 35 - Warning: missing <tr>
line 1033 column 50 - Warning: missing </font> before </td>
line 1034 column 37 - Warning: unescaped & or unknown entity "&id"
line 1033 column 184 - Warning: missing </font> before </table>
line 1035 column 17 - Warning: discarding unexpected </textarea>
line 1035 column 28 - Warning: discarding unexpected </form>
line 1035 column 35 - Warning: discarding unexpected </embed>
line 1035 column 43 - Warning: discarding unexpected </noembed>
line 1035 column 53 - Warning: discarding unexpected </noscript>
line 1035 column 64 - Warning: discarding unexpected </noembed>
line 1035 column 74 - Warning: discarding unexpected </embed>
line 1035 column 82 - Warning: discarding unexpected </table>
line 1035 column 90 - Warning: discarding unexpected </table>
line 1037 column 9 - Warning: missing </font> before <table>
line 1049 column 25 - Warning: discarding unexpected </font>
line 1058 column 58 - Warning: discarding unexpected </font>
line 1036 column 1 - Warning: missing </center>
line 120 column 63 - Warning: <img> lacks "alt" attribute
line 125 column 19 - Warning: <td> attribute "width" has invalid value "120px"
line 125 column 93 - Warning: <img> lacks "alt" attribute
line 141 column 19 - Warning: <td> attribute "width" has invalid value "120px"
line 141 column 98 - Warning: <img> lacks "alt" attribute
line 148 column 44 - Warning: <img> proprietary attribute value "absmiddle"
line 148 column 142 - Warning: <img> proprietary attribute value "absmiddle"
line 148 column 245 - Warning: <img> proprietary attribute value "absmiddle"
line 161 column 22 - Warning: <img> lacks "alt" attribute
line 161 column 63 - Warning: <img> lacks "alt" attribute
line 161 column 112 - Warning: <img> lacks "alt" attribute
line 161 column 162 - Warning: <img> lacks "alt" attribute
line 162 column 11 - Warning: <img> lacks "alt" attribute
line 172 column 15 - Warning: <img> lacks "alt" attribute
line 189 column 617 - Warning: <img> proprietary attribute value "absmiddle"
line 189 column 617 - Warning: <img> lacks "alt" attribute
line 213 column 2259 - Warning: <img> proprietary attribute value "absmiddle"
line 213 column 2259 - Warning: <img> lacks "alt" attribute
line 219 column 2373 - Warning: <img> lacks "alt" attribute
line 224 column 3036 - Warning: <img> lacks "alt" attribute
line 238 column 4496 - Warning: <img> lacks "alt" attribute
line 253 column 5356 - Warning: <img> lacks "alt" attribute
line 262 column 22 - Warning: <img> lacks "alt" attribute
line 262 column 63 - Warning: <img> lacks "alt" attribute
line 262 column 112 - Warning: <img> lacks "alt" attribute
line 262 column 162 - Warning: <img> lacks "alt" attribute
line 273 column 15 - Warning: <img> lacks "alt" attribute
line 288 column 803 - Warning: <img> proprietary attribute value "absmiddle"
line 288 column 803 - Warning: <img> lacks "alt" attribute
line 288 column 856 - Warning: <img> proprietary attribute value "absmiddle"
line 288 column 856 - Warning: <img> lacks "alt" attribute
line 296 column 22 - Warning: <img> lacks "alt" attribute
line 296 column 63 - Warning: <img> lacks "alt" attribute
line 296 column 112 - Warning: <img> lacks "alt" attribute
line 296 column 162 - Warning: <img> lacks "alt" attribute
line 297 column 11 - Warning: <img> lacks "alt" attribute
line 307 column 15 - Warning: <img> lacks "alt" attribute
line 319 column 1002 - Warning: <img> proprietary attribute value "absmiddle"
line 319 column 1002 - Warning: <img> lacks "alt" attribute
line 329 column 22 - Warning: <img> lacks "alt" attribute
line 329 column 63 - Warning: <img> lacks "alt" attribute
line 329 column 112 - Warning: <img> lacks "alt" attribute
line 329 column 162 - Warning: <img> lacks "alt" attribute
line 340 column 15 - Warning: <img> lacks "alt" attribute
line 347 column 128 - Warning: <img> proprietary attribute value "absmiddle"
line 347 column 128 - Warning: <img> lacks "alt" attribute
line 350 column 378 - Warning: <img> lacks "alt" attribute
line 358 column 22 - Warning: <img> lacks "alt" attribute
line 358 column 63 - Warning: <img> lacks "alt" attribute
line 358 column 112 - Warning: <img> lacks "alt" attribute
line 358 column 162 - Warning: <img> lacks "alt" attribute
line 369 column 15 - Warning: <img> lacks "alt" attribute
line 388 column 1767 - Warning: <img> proprietary attribute value "absmiddle"
line 388 column 1767 - Warning: <img> lacks "alt" attribute
line 388 column 1820 - Warning: <img> proprietary attribute value "absmiddle"
line 388 column 1820 - Warning: <img> lacks "alt" attribute
line 396 column 22 - Warning: <img> lacks "alt" attribute
line 396 column 63 - Warning: <img> lacks "alt" attribute
line 396 column 112 - Warning: <img> lacks "alt" attribute
line 396 column 162 - Warning: <img> lacks "alt" attribute
line 407 column 15 - Warning: <img> lacks "alt" attribute
line 414 column 694 - Warning: <img> lacks "alt" attribute
line 438 column 5127 - Warning: <img> lacks "alt" attribute
line 438 column 5286 - Warning: <img> lacks "alt" attribute
line 446 column 22 - Warning: <img> lacks "alt" attribute
line 446 column 63 - Warning: <img> lacks "alt" attribute
line 446 column 112 - Warning: <img> lacks "alt" attribute
line 446 column 162 - Warning: <img> lacks "alt" attribute
line 447 column 11 - Warning: <img> lacks "alt" attribute
line 457 column 15 - Warning: <img> lacks "alt" attribute
line 471 column 1289 - Warning: <img> lacks "alt" attribute
line 473 column 1366 - Warning: <img> lacks "alt" attribute
line 480 column 15 - Warning: <img> proprietary attribute value "absmiddle"
line 480 column 15 - Warning: <img> lacks "alt" attribute
line 480 column 58 - Warning: <img> proprietary attribute value "absmiddle"
line 480 column 58 - Warning: <img> lacks "alt" attribute
line 480 column 101 - Warning: <img> proprietary attribute value "absmiddle"
line 480 column 101 - Warning: <img> lacks "alt" attribute
line 480 column 144 - Warning: <img> proprietary attribute value "absmiddle"
line 480 column 144 - Warning: <img> lacks "alt" attribute
line 480 column 187 - Warning: <img> proprietary attribute value "absmiddle"
line 480 column 187 - Warning: <img> lacks "alt" attribute
line 480 column 230 - Warning: <img> proprietary attribute value "absmiddle"
line 480 column 230 - Warning: <img> lacks "alt" attribute
line 481 column 22 - Warning: <img> lacks "alt" attribute
line 481 column 63 - Warning: <img> lacks "alt" attribute
line 481 column 112 - Warning: <img> lacks "alt" attribute
line 481 column 162 - Warning: <img> lacks "alt" attribute
line 482 column 11 - Warning: <img> lacks "alt" attribute
line 492 column 15 - Warning: <img> lacks "alt" attribute
line 508 column 22 - Warning: <img> lacks "alt" attribute
line 508 column 63 - Warning: <img> lacks "alt" attribute
line 508 column 112 - Warning: <img> lacks "alt" attribute
line 508 column 162 - Warning: <img> lacks "alt" attribute
line 509 column 11 - Warning: <img> lacks "alt" attribute
line 519 column 15 - Warning: <img> lacks "alt" attribute
line 526 column 131 - Warning: <img> proprietary attribute value "absmiddle"
line 526 column 131 - Warning: <img> lacks "alt" attribute
line 534 column 22 - Warning: <img> lacks "alt" attribute
line 534 column 63 - Warning: <img> lacks "alt" attribute
line 534 column 112 - Warning: <img> lacks "alt" attribute
line 534 column 162 - Warning: <img> lacks "alt" attribute
line 545 column 15 - Warning: <img> lacks "alt" attribute
line 552 column 694 - Warning: <img> lacks "alt" attribute
line 581 column 4653 - Warning: <img> lacks "alt" attribute
line 581 column 4812 - Warning: <img> lacks "alt" attribute
line 589 column 22 - Warning: <img> lacks "alt" attribute
line 589 column 63 - Warning: <img> lacks "alt" attribute
line 589 column 112 - Warning: <img> lacks "alt" attribute
line 589 column 162 - Warning: <img> lacks "alt" attribute
line 590 column 11 - Warning: <img> lacks "alt" attribute
line 600 column 15 - Warning: <img> lacks "alt" attribute
line 610 column 1350 - Warning: <img> proprietary attribute value "absmiddle"
line 610 column 1350 - Warning: <img> lacks "alt" attribute
line 671 column 22 - Warning: <img> lacks "alt" attribute
line 671 column 63 - Warning: <img> lacks "alt" attribute
line 671 column 112 - Warning: <img> lacks "alt" attribute
line 671 column 162 - Warning: <img> lacks "alt" attribute
line 682 column 15 - Warning: <img> lacks "alt" attribute
line 689 column 694 - Warning: <img> lacks "alt" attribute
line 692 column 2388 - Warning: <img> proprietary attribute value "absmiddle"
line 692 column 2388 - Warning: <img> lacks "alt" attribute
line 738 column 6846 - Warning: <img> lacks "alt" attribute
line 738 column 7005 - Warning: <img> lacks "alt" attribute
line 746 column 22 - Warning: <img> lacks "alt" attribute
line 746 column 63 - Warning: <img> lacks "alt" attribute
line 746 column 112 - Warning: <img> lacks "alt" attribute
line 746 column 162 - Warning: <img> lacks "alt" attribute
line 747 column 11 - Warning: <img> lacks "alt" attribute
line 757 column 15 - Warning: <img> lacks "alt" attribute
line 780 column 22 - Warning: <img> lacks "alt" attribute
line 780 column 63 - Warning: <img> lacks "alt" attribute
line 780 column 112 - Warning: <img> lacks "alt" attribute
line 780 column 162 - Warning: <img> lacks "alt" attribute
line 791 column 15 - Warning: <img> lacks "alt" attribute
line 798 column 694 - Warning: <img> lacks "alt" attribute
line 816 column 4013 - Warning: <img> lacks "alt" attribute
line 816 column 4172 - Warning: <img> lacks "alt" attribute
line 824 column 22 - Warning: <img> lacks "alt" attribute
line 824 column 63 - Warning: <img> lacks "alt" attribute
line 824 column 112 - Warning: <img> lacks "alt" attribute
line 824 column 162 - Warning: <img> lacks "alt" attribute
line 825 column 11 - Warning: <img> lacks "alt" attribute
line 835 column 15 - Warning: <img> lacks "alt" attribute
line 845 column 855 - Warning: <img> proprietary attribute value "absmiddle"
line 845 column 855 - Warning: <img> lacks "alt" attribute
line 854 column 22 - Warning: <img> lacks "alt" attribute
line 854 column 63 - Warning: <img> lacks "alt" attribute
line 854 column 112 - Warning: <img> lacks "alt" attribute
line 854 column 162 - Warning: <img> lacks "alt" attribute
line 865 column 15 - Warning: <img> lacks "alt" attribute
line 872 column 694 - Warning: <img> lacks "alt" attribute
line 877 column 2004 - Warning: <img> lacks "alt" attribute
line 885 column 3499 - Warning: <img> lacks "alt" attribute
line 885 column 3658 - Warning: <img> lacks "alt" attribute
line 893 column 22 - Warning: <img> lacks "alt" attribute
line 893 column 63 - Warning: <img> lacks "alt" attribute
line 893 column 112 - Warning: <img> lacks "alt" attribute
line 893 column 162 - Warning: <img> lacks "alt" attribute
line 894 column 11 - Warning: <img> lacks "alt" attribute
line 904 column 15 - Warning: <img> lacks "alt" attribute
line 918 column 750 - Warning: <img> lacks "alt" attribute
line 926 column 22 - Warning: <img> lacks "alt" attribute
line 926 column 63 - Warning: <img> lacks "alt" attribute
line 926 column 112 - Warning: <img> lacks "alt" attribute
line 926 column 162 - Warning: <img> lacks "alt" attribute
line 937 column 15 - Warning: <img> lacks "alt" attribute
line 944 column 694 - Warning: <img> lacks "alt" attribute
line 944 column 1722 - Warning: <img> proprietary attribute value "absmiddle"
line 944 column 1722 - Warning: <img> lacks "alt" attribute
line 946 column 2181 - Warning: <img> lacks "alt" attribute
line 946 column 2340 - Warning: <img> lacks "alt" attribute
line 954 column 22 - Warning: <img> lacks "alt" attribute
line 954 column 63 - Warning: <img> lacks "alt" attribute
line 954 column 112 - Warning: <img> lacks "alt" attribute
line 954 column 162 - Warning: <img> lacks "alt" attribute
line 955 column 11 - Warning: <img> lacks "alt" attribute
line 965 column 15 - Warning: <img> lacks "alt" attribute
line 997 column 22 - Warning: <img> lacks "alt" attribute
line 997 column 63 - Warning: <img> lacks "alt" attribute
line 997 column 112 - Warning: <img> lacks "alt" attribute
line 997 column 162 - Warning: <img> lacks "alt" attribute
line 1008 column 15 - Warning: <img> lacks "alt" attribute
line 1015 column 694 - Warning: <img> lacks "alt" attribute
line 1021 column 1992 - Warning: <img> lacks "alt" attribute
line 1025 column 2762 - Warning: <img> lacks "alt" attribute
line 1025 column 2921 - Warning: <img> lacks "alt" attribute
line 1034 column 44 - Warning: <img> proprietary attribute value "absmiddle"
line 1034 column 142 - Warning: <img> proprietary attribute value "absmiddle"
line 1034 column 245 - Warning: <img> proprietary attribute value "absmiddle"
line 1043 column 25 - Warning: <img> lacks "alt" attribute
line 1048 column 267 - Warning: <img> lacks "alt" attribute
line 414 column 1512 - Warning: trimming empty <font>
line 689 column 1512 - Warning: trimming empty <font>
line 693 column 2446 - Warning: trimming empty <font>
line 798 column 1512 - Warning: trimming empty <font>
line 1028 column 17 - Warning: trimming empty <tr>
line 125 column 68 - Warning: <nobr> is not approved by W3C
line 141 column 68 - Warning: <nobr> is not approved by W3C
line 177 column 27 - Warning: <nobr> is not approved by W3C
line 278 column 27 - Warning: <nobr> is not approved by W3C
line 312 column 27 - Warning: <nobr> is not approved by W3C
line 345 column 27 - Warning: <nobr> is not approved by W3C
line 374 column 27 - Warning: <nobr> is not approved by W3C
line 412 column 27 - Warning: <nobr> is not approved by W3C
line 414 column 158 - Warning: <table> proprietary attribute "height"
line 414 column 223 - Warning: <td> proprietary attribute "background"
line 414 column 319 - Warning: <td> proprietary attribute "background"
line 414 column 409 - Warning: <table> proprietary attribute "height"
line 414 column 489 - Warning: <td> proprietary attribute "background"
line 414 column 1444 - Warning: <td> proprietary attribute "background"
line 462 column 27 - Warning: <nobr> is not approved by W3C
line 497 column 27 - Warning: <nobr> is not approved by W3C
line 524 column 27 - Warning: <nobr> is not approved by W3C
line 550 column 27 - Warning: <nobr> is not approved by W3C
line 552 column 158 - Warning: <table> proprietary attribute "height"
line 552 column 223 - Warning: <td> proprietary attribute "background"
line 552 column 319 - Warning: <td> proprietary attribute "background"
line 552 column 409 - Warning: <table> proprietary attribute "height"
line 552 column 489 - Warning: <td> proprietary attribute "background"
line 552 column 1444 - Warning: <td> proprietary attribute "background"
line 605 column 27 - Warning: <nobr> is not approved by W3C
line 687 column 27 - Warning: <nobr> is not approved by W3C
line 689 column 158 - Warning: <table> proprietary attribute "height"
line 689 column 223 - Warning: <td> proprietary attribute "background"
line 689 column 319 - Warning: <td> proprietary attribute "background"
line 689 column 409 - Warning: <table> proprietary attribute "height"
line 689 column 489 - Warning: <td> proprietary attribute "background"
line 689 column 1444 - Warning: <td> proprietary attribute "background"
line 762 column 27 - Warning: <nobr> is not approved by W3C
line 796 column 27 - Warning: <nobr> is not approved by W3C
line 798 column 158 - Warning: <table> proprietary attribute "height"
line 798 column 223 - Warning: <td> proprietary attribute "background"
line 798 column 319 - Warning: <td> proprietary attribute "background"
line 798 column 409 - Warning: <table> proprietary attribute "height"
line 798 column 489 - Warning: <td> proprietary attribute "background"
line 798 column 1444 - Warning: <td> proprietary attribute "background"
line 840 column 27 - Warning: <nobr> is not approved by W3C
line 870 column 27 - Warning: <nobr> is not approved by W3C
line 872 column 158 - Warning: <table> proprietary attribute "height"
line 872 column 223 - Warning: <td> proprietary attribute "background"
line 872 column 319 - Warning: <td> proprietary attribute "background"
line 872 column 409 - Warning: <table> proprietary attribute "height"
line 872 column 489 - Warning: <td> proprietary attribute "background"
line 872 column 1444 - Warning: <td> proprietary attribute "background"
line 909 column 27 - Warning: <nobr> is not approved by W3C
line 942 column 27 - Warning: <nobr> is not approved by W3C
line 944 column 158 - Warning: <table> proprietary attribute "height"
line 944 column 223 - Warning: <td> proprietary attribute "background"
line 944 column 319 - Warning: <td> proprietary attribute "background"
line 944 column 409 - Warning: <table> proprietary attribute "height"
line 944 column 489 - Warning: <td> proprietary attribute "background"
line 944 column 1444 - Warning: <td> proprietary attribute "background"
line 970 column 27 - Warning: <nobr> is not approved by W3C
line 1013 column 27 - Warning: <nobr> is not approved by W3C
line 1015 column 158 - Warning: <table> proprietary attribute "height"
line 1015 column 223 - Warning: <td> proprietary attribute "background"
line 1015 column 319 - Warning: <td> proprietary attribute "background"
line 1015 column 409 - Warning: <table> proprietary attribute "height"
line 1015 column 489 - Warning: <td> proprietary attribute "background"
line 1015 column 1444 - Warning: <td> proprietary attribute "background"
Info: Document content looks like HTML5
Info: No system identifier in emitted doctype
Tidy found 440 warnings and 0 errors!


The alt attribute should be used to give a short description
of an image; longer descriptions should be given with the
longdesc attribute which takes a URL linked to the description.
These measures are needed for people using non-graphical browsers.

For further advice on how to make your pages accessible
see http://www.w3.org/WAI/GL.
You are recommended to use CSS to specify the font and
properties such as its size and color. This will reduce
the size of HTML files and make them easier to maintain
compared with using <FONT> elements.

You are recommended to use CSS to control line wrapping.
Use "white-space: nowrap" to inhibit wrapping in place
of inserting <NOBR>...</NOBR> into the markup.

About HTML Tidy: https://github.com/htacg/tidy-html5
Bug reports and comments: https://github.com/htacg/tidy-html5/issues
Official mailing list: https://lists.w3.org/Archives/Public/public-htacg/
Latest HTML specification: http://dev.w3.org/html5/spec-author-view/
Validate your HTML documents: http://validator.w3.org/nu/
Lobby your company to join the W3C: http://www.w3.org/Consortium

Do you speak a language other than English, or a different variant of
English? Consider helping us to localize HTML Tidy. For details please see
https://github.com/htacg/tidy-html5/blob/master/README/LOCALIZE.md