• Create Account

# intyuh

Member Since 20 Jan 2011
Offline Last Active Jul 31 2015 01:26 AM

### #5223915Cosine weighted mapping explanations

Posted by on 17 April 2015 - 04:12 AM

Ok, first post in many years, and I managed to finally find the answer minutes after asking the question (I've been trying to find it for 1 whole day before that) and it's so simple I'm a bit ashamed ^^'

Anyway, if anyone stumble onto this post with the same question, here is a quick explanation.

```    ^
|
1-u |------/
|     /
|    /
|   / H
|o /
| /
|/___________>
```

Forgive my poor ascii art, but it's easier to understand this way ^^'
Here, o is the theta angle. Since we're sampling on a unit sphere, H is always of length 1. This leads to cos(o) = 1-u for the uniform mapping, all good.

Now for the cosine weighted one, H is no longer of length 1 (that's what I had wrong) : its length is what's weighted by the cosine ! So in fact : |H| = cos(o)
And now, we have the following : cos(o) = (1-u) / |H| = (1-u) / cos(o)
And this leads to cos(o) = sqrt(1-u)

One day to come up with that ... I feel a bit dumb, but still glad to finally understand this completely ^^'

Posted by on 21 June 2011 - 02:50 PM

Why don't you use your own format ? A simple one which only contains what you use in your engine ? If you're going to write a collada parser, you could easily make it output the stuff you need in a compact / easy to read and use format then ^^
This would be easier to parse/load (and also faster since you can get rid of all the collada stuff you don't need, and god knows how much of that there is ^^)

That's the path im leaning towards since I can't find any collada parsers out there and I already have a script that handles geometry data and some material stuff.

My biggest concern is limiting graphics artists later down the road. I've never worked with a graphics artist before so I'm not sure if it is a big deal for them to follow a certain collada format or not. Any graphical artists out there care to comment on the difficulties of following a limited collada spec?

Thanks!

Hi again,

You WILL have to limit your graphists : the Collada format is so complex that you can't possibly write a parser that will cover everything your graphists will do. So in my opinion, you're better of writing your own exporter/parser.

I had the exact same problem in my previous work. We reached a point where we couldn't use the basic format we were using at the beginning (the DirectX .x format ^^) and we had to choose between
- using an existing format that would cover all our needs (present and in the near future at least)
- writing our own exporter

I ended up writing a Maya loader/exporter with a little custom file format. Note that we only used Maya, so I could directly use the Maya API and not bother with interop with other 3D softwares. If you're going to allow many different software, then the "custom expoter" approach won't work.

Anyway, I couldn't possibly write an exporter that could handle everything Maya does, so I had a lot of "brainstorming" with the graphists to understand what their needs were and would be. We decided on a workflow that was acceptable for both parts : simple enough for me to keep the exporter simple and flexible enough for them to work quickly / efficiently.
Once this part was done, it was quite simple. They had a documentation of what was supported, how to export various stuff, and if they needed something new, they'd simply asked (I usually answered by "you won't need this, it'll break ingame performances !" ^^)

So the moral : if you have a basic collada parser, continue to work on it, but you should find a graphist as soon as possible to discuss with him what will his needs be. And improve your parser accordingly, this is perfectly fine. Most graphists used to production will be used to following a certain workflow.
Also, don't simply ask him "send me a list of what you need" ... you'll end up writing a full Collada parser

Posted by on 21 June 2011 - 09:15 AM

Why don't you use your own format ? A simple one which only contains what you use in your engine ? If you're going to write a collada parser, you could easily make it output the stuff you need in a compact / easy to read and use format then ^^
This would be easier to parse/load (and also faster since you can get rid of all the collada stuff you don't need, and god knows how much of that there is ^^)

### #4816146What is Microsofts problem?

Posted by on 26 May 2011 - 01:30 PM

Having developed on every platforms and most of the consoles/devices out there. I find Visual Studio the best IDE that exists. It has its problems, but its still the best in my opinion.
Only bad thing about it personally is the intellisens. And if your employer is too cheap to buy you a licence of VisualAssist (My case) then it's a bit troublesome. But I never had problems with libraries dependencies and I've used them a lot. Not sure what you are talking about?

XCode was a nightmare to work with in my case. I guess it's a matter of taste/experience with one more than the other. Very bad post tho. I believe Microsoft cares more about its developers than its concurrents. Giving Android as an example is a very bad example. Just try to code a C++ app on android. That was a hell of a nightmare with not even a STL implementation. Same things goes as Xbox dev vs PS3 dev, etc. Microsoft always win as developer support and softwares.

Seconded ! The second part about XCode and Android even made me smile (I'm currently working on iPhone and Android, so I know what it's like )

As for the op : do you even have a real question ? Or are you just trolling ?

### #4808591Terrain silhouette

Posted by on 09 May 2011 - 10:21 AM

Ive read the paper again, and it seems my implementation is missing somethings

For what, Ive understood the coarser levels are only updated when the next vertex position is exactly in the position of the old vertex (well I didnt explained it very well )

"The choice of grid size n = 2k−1 has the further advantage that the finer level is never
exactly centered with respect to its parent next-coarser level. In other words, it is always
offset by 1 grid unit either left or right, as well as either top or bottom (see Figure 2-4),
depending on the position of the viewpoint."

This 1 grid unit offset is the L-shaped strip right? But how do this prevent levels from overlapping?

Quick answer : there always is a gap between 2 levels. This gap allow you to move the finer level one unit without moving the next coarser one. The L-shape is there to fill the gap. When your finer level move so that it will overlap the next coarser level, then and only then you move your coarser level.

Long answer : English is not my primary language, so explaining something like this in english is a bit above my abilities (I've had a bit of trouble understanding the whole geometry mipmapping stuff myself )
What I would advice is : take a pen, a paper with a grid, and draw a sample case. This is what I did, and it helped me visualize the whole thing.
It's not so difficult, but explaining it by words is

PARTNERS